System and method for performing processing in a testing system

ABSTRACT

System and methods can execute processes in a test system. A flexible platform may be provided for developing test programs for performing automated testing. For example, the tester and its instruments are isolated from the tester operating system, permitting any tester operating system to be used. In another example implementation, a user layer of the platform is isolated from the physical layer of the architecture, permitting hardware-independent test programs that can be created and used among different testers having different test hardware and software. In yet another implementation, execution of a test program is isolated from a tester platform operating system, permitting the test program to function independent from the tester platform. Functionality can be implemented on the platform such that functions are only added, and that existing links to functions are not broken, ensuring continued test system operation when new software, hardware and/or features are added to the platform.

REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority under 35U.S.C. §120 to U.S. patent application Ser. No. 11/827,083, entitled“SYSTEM AND METHOD FOR PERFORMING PROCESSING IN A TESTING SYSTEM,” filedJul. 10, 2007, now U.S. Pat. No. 9,032,384, which claims priority toU.S. Provisional Application Ser. No. 60/819,610, entitled “SYSTEM ANDMETHOD FOR PERFORMING PROCESSING IN A TESTING SYSTEM,” filed Jul. 10,2006, and to U.S. Provisional Application Ser. No. 60/819,762, entitled“SYSTEM AND METHOD FOR PROCESSING IN A TEST SYSTEM,” filed Jul. 10,2006, each of which applications are incorporated by reference in theirentirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates generally to test systems, and more specifically,to test systems in the automatic test equipment (ATE) area.

2. Discussion of the Related Art

Today, most test equipment in the ATE area involves one or more computersystems. A computer system that implements testing steps must bereliable and must generate test steps in a deterministic way. That is,the computer systems must be capable of producing consistent results.One problem with such a computer is cost—design of a complete computingsystem suitable for use in testing (e.g., one that produces consistentresults) requires not only the expensive hardware design and maintenancebut also expensive software design involving operating system, userinterface, drivers, tools, etc. More particularly, deterministicexecution can be achieved using expensive computing hardware andsoftware and/or distributed hardware within the tester, such asindividual control processors within the instrument or other testingresource. As a result, computer systems suitable for ATE areprohibitively expensive for most companies to purchase and maintain.

Automated test equipment (ATE) is computer-controlled equipment thattests electronic devices for functionality and performance. ATE devicesalso conduct stress testing with minimal human interaction. A typicalATE tester includes control hardware, sensors, and software thatcollects and analyzes the test results. Such an ATE tester relies onparticular test instruments to perform the testing and return results tothe control software. Conventional ATE testers and methodologies arewidely considered to only be cost efficient for high-volume testing.

This widely held belief stems, in part, from the design and operation ofconventional ATE testers. As it stands now, a manufacturer can create anew device or system. A key element in the design and construction ofany new device or system is the ability to test the device or system forquality, functionality, and serviceability. The first step in testingthat new device is to determine if anyone already has a tester designedand working that may cover the new device. If one does not exist, theonly option is to have a suitable tester built. The current marketplacetakes a long time to determine if a new tester should be built, letalone to begin actual construction of such a tester. Determining whetheror not a new tester covering the new device would have wide demand, orany at all beyond the single use, ultimately determines whether the newtester will be made. If it does not, that often ends the possibility ofgetting a new tester. If it does, the new tester still must be designedand fabricated. An average time for completing such a process is on theorder of years. For instance, it is not uncommon for it to take two ormore years to produce a new tester. In that time frame, mostmanufacturers are already looking to test a newer device, so such testermay be obsolete even before it is released.

SUMMARY OF THE INVENTION

According to one aspect of the present invention, it is appreciated thatsuch ATE systems are expensive due to the fact that they arespecially-developed systems that have limited applications, among otherreasons. Because they are highly specialized, they do not lendthemselves to be mass-produced, or include mass-produced hardware andsoftware components. In one aspect of the invention, it is appreciatedthat it would be beneficial to produce an ATE system using lessexpensive, more general-purpose components.

Further, according to one aspect of the present invention, it isappreciated that the total cost of ATE systems are expensive dueprimarily to the tight coupling between software and hardware. Morespecifically, components of the ATE system such as the operatingsystems, test platforms, their associated applications, and underlyingtest hardware depend on each other, and when one of these components arechanged, the ATE system may not function in the same manner prior to thechange. In a deterministic system such as an ATE system, such a changemay cause a test program to perform differently, producingnon-deterministic test results.

Practically, in a production test environment, this results in user(e.g., test engineers) being reluctant to implement new features inexisting production test systems. For instance, if a new software-basedtest function is made available in an existing test system, introductionof that new software may break the operation of the current software.For instance, if a software driver is replaced by a later-versiondriver, the test system may not function in the same way, and testresults may be affected. Similarly, if an improved hardware (e.g., atest instrument) is added to an existing ATE system, the hardware and/orsoftware of the existing system may not function in the same way or atall. As a result, test engineers generally do not disturb existing testsystems to implement new functionality, but rather would purchase newhardware and software for performing new test functions. This results ininefficient use of testing resources, and limited reuse of testingplatforms. Further, the test hardware and software producer mustrigorously test all possible permutations of components to prohibitproblems from occurring in the field, thus increasing production costsand the overall cost of the test equipment.

Further, test engineers may develop their own testing programs that usehardware and software of the ATE. Because their programs use thetightly-coupled hardware and software, their programs are also highlydependent on this tightly-coupled system, and any changes in theunderlying system may cause their test programs to operate differentlythan expected. Because of this, test engineers are generally unwillingto consider new software and/or hardware changes to existing productiontest environments. Such test equipment may be used, for example, inmanufacturing of electronic devices, and a failure of such equipment mayimpact manufacturing schedules.

According to one aspect of the present invention, a platform is providedthat permits components (e.g., hardware, software) to be changed withoutaffecting the operation of other components. For instance, in a testenvironment, a test development platform may include test systemsoftware, software drivers used to communicate with various testinstruments, and operating system software. According to one aspect, anarchitecture is provided that isolates the function of such componentsto reduce the amount of coupling between the components. In this way,the changing of one component does not affect the operation of othercomponents.

For instance, when adding a component, the addition of the componentdoes not disturb the function of other components. In one specificexample, a portion of test hardware (e.g., a test instrument) failswhich needs to be replaced. However, only a new version of the testhardware is available. This new version has a different interface thanthe failed test hardware, and it follows that the software andapplications that access the new hardware need to be changed to adapt tothe new interface. Unfortunately, this change results in increasedmaintenance costs for the test system, as all test programs andapplications that used the old hardware will need to be changed andretested, as the communication between hardware and software was broken.However, in some cases, the user has no choice, as equipmentmanufacturers frequently change hardware and software, causing theoverall system not to work.

According to one aspect of the present invention, it is appreciated thattesting applications and their associated software (e.g., platform OS,drivers) and hardware are tightly coupled. In one embodiment, anabstraction layer is provided that decouples the testing applicationfrom hardware. According to one embodiment, a virtual instrument isprovided that presents a common interface to a user. The interface,according to one embodiment, does not change when the underlyinghardware changes, reducing the possibility that the application will notwork when changes are made. Further, it follows that an applicationdeveloped using the virtual instrument can be used among systems havingdifferent hardware types and/or versions, as hardware-specificimplementations are, according to one embodiment, abstracted from theapplication.

In one implementation, a system architecture is provide that is modular,linked by interfaces. In one implementation, modules are linked byadd-only interfaces, wherein functionality can be only added toparticular interfaces, thereby ensuring that existing code and testprograms are not “broken.” In another implementation, such interfacesare abstracted to only those functions that are specifically necessary.

Further, according to another aspect of the present invention, it isrealized that there is a significant benefit to bringing new automatedtesting solutions to market faster. In particular, an automated testequipment platform that reduces the time it takes to create a new testerwould be beneficial. Further, it is appreciated that it would bebeneficial to have the ability to produce testers without requiring wideapplicability before fabrication. Moreover, a tester that couldincorporate new functionality without requiring the design of a newtester would be beneficial.

A flexible tester that can be fabricated in a shorter time, that is costefficient, and adaptable to cover new devices will meet the needs of themarketplace. Although, there have been attempts to design such testers,conventional architectures still result in hardware specific code beingincorporated with system code making them dependant on specific hardwareand rendering them useful in only a narrow range of applications. Theinterdependence and intermingling of function and software limitsconventional ATE testers. Under conventional methodologies any change(additions or subtractions of hardware, and in some cases replacement ofidentical parts) can result in a tester that does not function properly.Restoring the changed ATE tester to proper function requires additionalexpenses and increases time to market for the devices to be tested.

The inflexibility of conventional ATE testers increases the costsassociated with developing and maintaining testers. With conventionalmethods, development of new testers generally requires construction fromscratch and fails to leverage what is already in place. One aspect ofthe present invention describes an instrument developer platformdefining a set of architecture standards that enable the timelydevelopment of new ATE testers that can test a virtually unlimited rangeof devices. This architecture also allows for the modification ofexisting testers to include new instrumentation without requiringchanges to existing test functionality and its related software. Thistest system architecture is able to incorporate new instrumentation intoan existing tester, and thus leverage what is in place. This isaccomplished through the abstraction of sets of functionality in an ATEtester.

In one implementation of the present invention, an instrumentincorporated into a particular tester is abstracted into a functionalmodule. This abstracted module manages the functions of the particularinstrument while remaining independent of the rest of the ATE tester. Inparticular, interfaces defined at a platform level allow forindependence of the test platform itself. When the functionality of theinstrument is employed to test a particular device, the module is calledby other independent abstraction layers. The module, independent of theabstraction layer(s) which called it, manages the functions of theinstrument and the module returns the results to the that abstractionlayer. In this example, the tester interacts with the module onlythrough other independent abstraction layers, the module and its relatedinstrument is permitted to be “plugged-in” to any tester that employsthe same architecture. For instance, the module and the relatedinstrument can be removed from one tester and by installing the samemodule and instrument on another tester (of the same architecture), thefunctionality of the second tester is enhanced without impacting theexisting functions of the second tester. Moreover, in this example, thefirst tester, from which a module and instrument were extracted, willcontinue to function with the remaining instruments available to it.Adhering to the architecture standards enables flexibility on existingtesters, cost efficiency, and greater speed to completion of newtesters.

In another aspect on the present invention, each level of functionalityof an ATE tester is abstracted, enabling sets of functions andfunctionalities to be separated in different layers encompassing thefunctions of an ATE tester. In one embodiment, users interact with testprograms, which bundle visualizations and graphically display resultsand options from tests performed, or to be performed, on a particulardevice. For instance, a single test program or multiple programs may beemployed by the user to test any particular device or devices. In aspectof the present invention, the abstraction of the functions andfunctionality provided by test program(s) forms the highest layer of theATE tester architecture.

Additionally, according to one aspect of the present invention, a systemis provided in which virtual instruments can be created and managed. Inone embodiment, the virtual instrument being modeled includes behaviorthat based on the functionality that is desired by the user, rather thanhardware-specific implementations. For instance, if a particularfunction is not natively performed in a software driver, thatfunctionality can be performed in software associated with the virtualinstrument. In this way, capabilities of test hardware and theirassociated drivers may be extended in a standard way. Further, accordingto another embodiment, because virtual instruments are created from theuser perspective, applications are more easily created.

Also, testers and their applications can be created more quickly, astesters are not tied to their hardware. Similarly, hardware associatedwith a tester can be improved more easily, as software is not so rigidlytied to hardware, and therefore, hardware can be added/changed withoutaffecting software (software will more easily work with hardware). It isappreciated that such a flexible platform for creating and maintainingsoftware and hardware is beneficial to the developer and maintainer ofsoftware, and the amount of cost and effort for creating and maintainingtesting programs is reduced.

According to another aspect of the present invention, a method forproviding software functions is provided that permits compatibilityacross software and hardware versions. According to one aspect of thepresent invention, functions of a virtual instrument that refer tohardware functions are unchanged from version to version. Moreparticularly, as functions are added to the virtual instrument, oldfunctions are maintained, and functionality is added to a predeterminedmemory structure. Functionality to software modules are added withoutchanging references of preexisting functions in memory. Because functionreferences are unchanged, additional functionality, when added to thememory structure does not “break” existing connections. Thus, when atest program is created, the program's functionality is frozen in time,as the functions that the test program accesses remain unchanged goingforward, unless the user decides to change the test program. In thisway, development and maintenance costs for creating and maintaining testprograms is significantly reduced.

According to one embodiment of the present invention, a virtual functiontable (e.g., in the C++ programming language, the well-known virtualmethod table (“vtable”)) is maintained for a virtual instrument. In oneembodiment, in one version of the virtual instrument vtable, a base setof functionality is included having a defined location in the vtable. Ina subsequent version of the virtual instrument table, additionalfunctions are added to the vtable, while maintaining the same locationin the vtable for the base set of functionality. In this way, functionsand their connections to other software are maintained without breakingexisting programs when additional functions are added.

According to another embodiment of the present invention, what isreferred to herein as a virtual multisite instrument is provided thatfacilitates management of multiple testing sites. In a traditionaltesting environment, it is appreciated that a site is managed as asingular entity in that if a particular testing site is configured, atest program is developed for the particular site, specific to theparticular testing hardware used. If multiple sites are needed toperform additional testing (e.g., to satisfy an increased testingcapacity), then additional test hardware configurations are purchased,and the test program is matriculated to the additional sites. Accordingto one aspect of the present invention, because details of theunderlying hardware is abstracted from test programs via an abstractionlayer (e.g., a virtual instrument layer), test programs can be managedindependent of test hardware, and the abstraction layer may be capableof managing the administration of a test program to multiple sites viathe abstraction layer. In one embodiment, the virtual instrument mayhave capability to map to multiple instrument sites. In this way, thetime needed to maintain and administer test programs to multiple sitesis reduced.

According to another aspect of the present invention, it is appreciatedthat test programs software is used by different types of users—someusers develop test applications, and others use the developedapplications for the administration and management of test processes.However, these separate types of users may need to use a specific userinterface (UI), depending on what functions are performed. It isappreciated that multiple types of testers have different userinterfaces, forcing the user to understand the specific type ofinterface necessary to run the equipment. Also, it is appreciated thatin the ATE industry, the application and drivers are tightly coupled,and the user interfaces are tied to the system software. According toone aspect of the present invention, a standard user interface may beused to access multiple tester types, reducing the amount of trainingnecessary for the user. To further reduce the amount of trainingrequired, a user-specific interface is provided that allows the user toperform testing functions related to their role.

Further, according to another aspect of the present invention, a testingarchitecture is provided that permits a user to perform testingfunctions from any location. In one specific implementation, the userinterface is accessed through a browser program, and a user may performtesting functions from any location coupled to a testing system througha communications network. In a traditional environment, the UI isnormally tied to the machine, however, if the UI is made available overa network, the user can perform testing from another location.

Further features and advantages of the present invention as well as thestructure and operation of various embodiments of the present inventionare described in detail below with reference to the accompanyingdrawings. In the drawings, like reference numerals indicate like orfunctionally similar elements. Additionally, the left-most one or twodigits of a reference numeral identifies the drawing in which thereference numeral first appears.

According to one aspect of the present invention, a system comprises atest program, an platform adapted to generate a plurality of functioncalls in response to requests from the test program, an abstractionlayer that is adapted to map the plurality of function calls intoinstructions to be executed on test hardware. According to oneembodiment of the present invention, the abstraction layer furthercomprises a virtual instrument (“VI”) interface to the platform.According to another embodiment of the invention, the abstraction layerfurther comprises a virtual multisite (“VMI”) interface to the platform.According to another embodiment of the invention, the abstraction layerfurther comprises a system physical instrument (“SystemPI”) interface tothe platform. According to another embodiment of the invention, theabstraction layer further comprises a physical instrument (“PI”)interface to the platform. According to another embodiment of theinvention, the abstraction layer further includes a virtual instrument(“VI”) to physical instrument (“PI”) interface.

According to one embodiment of the present invention, the abstractionlayer further includes a system physical instrument (“SystemPI”) tovirtual instrument (“VI”) interface. According to another embodiment ofthe invention, the abstraction layer further includes a system physicalinstrument (“SystemPI”) to physical instrument (“PI”) interface.According to another embodiment of the invention, the abstraction layerfurther includes a test program to virtual instrument (“VI”) interface.According to another embodiment of the invention, the abstraction layerfurther includes a test program to physical instrument (“PI”) interface.According to another embodiment of the invention, the abstraction layerfurther includes a platform to virtual instrument (“VI”) interface.According to another embodiment of the invention, the abstraction layerfurther includes a platform to physical instrument (“PI”) interface.According to another embodiment of the invention, the abstraction layerfurther includes a platform to virtual multisite instrument (“VMI”)interface.

According to one embodiment of the present invention, the abstractionlayer further comprises an interface generation engine. According toanother embodiment of the invention, the interface generation engineincludes a graphical user interface adapted to guide a user throughgeneration of an interface. According to another embodiment of theinvention, the interface generation engine generates an interface tomanage communication between components of the system. According toanother embodiment of the invention, the interface generation enginegenerates an interface to manage communication between components of theabstraction layer. According to another embodiment of the invention, theinterface generation engine generates an interface to managecommunication between the platform and the abstraction layer. Accordingto another embodiment of the invention, managing communication betweenthe platform and the abstraction layer includes mapping the plurality offunction calls to instructions to be executed on test hardware.According to another embodiment of the invention, mapping the pluralityof function calls includes mapping the plurality of function calls to avirtual instrument (“VI”) module. According to another embodiment of theinvention, mapping the plurality of function calls includes mapping theplurality of function calls to a system physical instrument (“SystemPI”) module. According to another embodiment of the invention, mappingthe plurality of function calls includes mapping the plurality offunction calls to a physical instrument (“PI”) module.

According to one embodiment of the present invention, mapping theplurality of function calls includes mapping a base class of physicalinstrument function calls to a physical instrument (“PI”) module.According to another embodiment of the invention, mapping the pluralityof function calls includes mapping a base class of physical instrumentfunction calls to a physical instrument (“PI”) module. According toanother embodiment of the invention, the abstraction layer furthercomprises a rules checking engine. According to another embodiment ofthe invention, the rules checking engine is adapted to verify themapping of function calls to instructions on the test hardware.According to another embodiment of the invention, the rules checkingengine verifies the mapping by simulating a request for the functioncall. According to another embodiment of the invention, the ruleschecking engine verifies the mapping by accepting a response as a resultof the simulated function call in an expected format. According toanother embodiment of the invention, the rules checking engine returns acode to the operating platform indicating that the function call wasmapped properly. According to another embodiment of the invention, therules checking engine identifies an improper mapping by accepting areturn code in response to the simulated function call that is not inthe expected format. According to another embodiment of the invention,the system further comprises an interface between the test program andthe platform.

According to one embodiment of the present invention, the test programprovides a graphical user interface to a user. According to anotherembodiment of the invention, the test program enables a user to definetests to be executed upon a device. According to another embodiment ofthe invention, the test program enables a user to define tests to beexecuted upon a device to occur at any time. According to anotherembodiment of the invention, the abstraction layer further comprises anphysical instrument abstraction layer representing the functionality ofhardware resources of the test system. According to another embodimentof the invention, the physical instrument abstraction layer includes aphysical instrument module that maps to a hardware resource. Accordingto another embodiment of the invention, the PI module causes executionof instructions on a hardware resource in response to requests.According to another embodiment of the invention, a hardware resourceincludes at least one function available on the test hardware. Accordingto another embodiment of the invention, the hardware resource is adaptedto cause the generation of a synchronization signal. According toanother embodiment of the invention, the hardware resource is adapted tocauses a device state query.

According to one embodiment of the present invention, the PI moduleincludes a function call that will cause a device to power on and/orinitialize in dependence upon a device starting state. According toanother embodiment of the invention, the physical instrument moduleincludes a base class of PI function calls. According to anotherembodiment of the invention, the base class of PI function callsincludes the power on and/or initialize function. According to anotherembodiment of the invention, the abstraction layer further comprises avirtual instrument abstraction layer that represents a virtualization ofhardware functions that may be performed on the test system. Accordingto another embodiment of the invention, the virtual instrumentabstraction layer includes a virtual instrument (“VI”) module, to whichat least one hardware resource is mapped. According to anotherembodiment of the invention, the VI module is adapted to cause theexecution of instructions on a hardware resource in response torequests. According to another embodiment of the invention, the mappingto at least one resource is mapped through at least one PI module foreach of the at least one hardware resource. According to anotherembodiment of the invention, the VI module is mapped to a plurality ofPI modules to render a virtual representation of a set of predefinedhardware resources employed to test a particular device.

According to one embodiment of the present invention, the VI module isadapted to be modified to include an additional PI module, expanding theset of hardware resources available to test a device through the VImodule. According to another embodiment of the invention, the VI moduleis adapted to include a base class of functions that map to testhardware resources necessary for any ATE tester. According to anotherembodiment of the invention, the abstraction layer further comprises asystem abstraction layer adapted to manage requests to hardwareresources. According to another embodiment of the invention, the systemabstraction layer is further adapted to map requests from a physicalinstrument layer so that hardware resources perform their functions inresponse to requests. According to another embodiment of the invention,the system abstraction layer is further adapted to define a base set ofsystem function calls available to other components of the abstractionlayer. According to another embodiment of the invention, the systemlayer further comprises a SystemPI module adapted to define a base setof system function calls that cause operations to be performed any theother components of the abstraction layer. According to anotherembodiment of the invention, the system abstraction layer is furtheradapted to perform queries on components of the abstraction layer.

According to one embodiment of the present invention, the systemabstraction layer includes a system physical instrument module.According to another embodiment of the invention, the platform layerincludes an “off the shelf” operating system. According to anotherembodiment of the invention, the “off the shelf” operating system isenhanced to perform deterministically. According to another embodimentof the invention, the “off the shelf” operating system is Windows XP,and it is enhanced using the Tenasys INtime operating system to operatedeterministically.

According to one aspect of the present invention, an automated testequipment system is provided. The system comprises a platformabstraction layer adapted to manage the operation of abstraction layersof the automated test equipment system, a physical instrument (“PI”)abstraction layer adapted to map PI function calls to hardware so thatthe hardware performs a function in response to a PI function call, avirtual instrument (“VI”) abstraction layer adapted to map to the PIabstraction layer so that the VI abstraction layer represents avirtualization of hardware functions that may be performed, a systemabstraction layer adapted to map system function calls to enable thehardware to perform functions in response to PI function calls, and atest program abstraction layer adapted to interact with the virtualinstrument layer to initiate functions performed on hardware. Accordingto one embodiment of the present invention, the system abstraction layeris further abstracted into a system physical instrument (“SystemPI”)module that receives requests from the PI abstraction layer and causeshardware to perform its function in response. According to anotherembodiment of the invention, the SystemPI module is further adapted toaggregate information reported by the other abstraction layers of theautomated test equipment system. According to another embodiment of theinvention, the information aggregated includes success or failure offunction calls made in the other abstraction layers of the automatedtest equipment system. According to another embodiment of the invention,the information aggregated includes reporting by operations in the otherabstraction layers of the automated test equipment system. According toanother embodiment of the invention, SystemPI module is further adaptedto accept queries on the information aggregated.

According to one embodiment of the present invention, SystemPI module isfurther adapted to report on the information aggregated. According toanother embodiment of the invention, the test program abstraction layerincludes a test program adapted to present a graphical user interface toa user. According to another embodiment of the invention, the testprogram layer is further adapted to permit a user to interact with thevirtual instrument layer. According to another embodiment of theinvention, the test program layer is further adapted to permit a user todefine tests to be performed on a device. According to anotherembodiment of the invention, the test program is further adapted tographically render the results of performed tests. According to anotherembodiment of the invention, the test program layer is further adaptedto permit a user to define tests to be performed on a device, whereinthe tests to be performed occur at a scheduled time. According toanother embodiment of the invention, tests to be performed can occur onany user defined schedule. According to another embodiment of theinvention, the virtual instrument abstraction layer includes a VImodule, wherein the VI module includes a mapping to at least onehardware resource.

According to one embodiment of the present invention, the VI module isadapted to cause the at least one hardware resource to perform itsfunction in response to requests. According to another embodiment of theinvention, the VI module causes the at least one hardware resource toperform its function in response to a request from the test programabstraction layer. According to another embodiment of the invention, themapping to the at least one hardware resource is mapped through the PIinstrument layer. According to another embodiment of the invention, themapping to the at least one hardware resource is mapped through a PImodule. According to another embodiment of the invention, the VI moduleis mapped to a plurality of PI modules so that the VI module renders avirtual representation of a plurality of hardware resources employed totest a device. According to another embodiment of the invention, themapping between the VI Module and the PI module is managed by aninterface. According to another embodiment of the invention, theinterface is a graphical user interface. According to another embodimentof the invention, the interface manages communication between the VIModule and the PI module in a predetermined format. According to anotherembodiment of the invention, the VI module is adapted to be modified toinclude a mapping to an additional PI module. According to anotherembodiment of the invention, the VI module is adapted to include a baseclass of functions that map to test hardware resources necessary for anyATE tester. According to another embodiment of the invention, thephysical instrument abstraction layer includes a PI module that containsthe implementation details of a hardware resource.

According to one embodiment of the present invention, the physicalinstrument abstraction layer includes a PI module that contains theimplementation details of each hardware resource. According to anotherembodiment of the invention, the physical instrument abstraction layeris adapted incorporate the implementation details of a new hardwareresource. According to another embodiment of the invention, the newhardware resource is mapped to by a new PI module. According to anotherembodiment of the invention, the PI module causes execution of thehardware resource's functionality in response to requests. According toanother embodiment of the invention, the request comes from a VI module.According to another embodiment of the invention, the hardwareresource's functionality includes a synchronization signal. According toanother embodiment of the invention, the physical instrument moduleincludes a function call that will cause a hardware resource to power onand/or initialize. According to another embodiment of the invention, thefunction call includes the PowerOnInitialize function. According toanother embodiment of the invention, the PI abstraction layer includes abase class of PI function calls. According to another embodiment of theinvention, the base class of PI function calls includes the functioncall adapted to cause a hardware resource to power on and/or initialize.

According to one embodiment of the present invention, the function calladapted to cause a hardware resource to power on and/or initializeincludes the PowerOnInitialize function. According to another embodimentof the invention, the platform abstraction layer includes an “off theshelf” operating system. According to another embodiment of theinvention, the “off the shelf” operating system is enhanced to performdeterministically. According to another embodiment of the invention, the“off the shelf” operating system is Windows XP. According to anotherembodiment of the invention, the operating system is enhanced to performdeterministically using real-time extensions. According to anotherembodiment of the invention, the real-time extensions are providedthrough the “Tenasys INtime” operating system. According to anotherembodiment of the invention, the platform abstraction layer operatesdeterministically.

According to another embodiment of the invention, the system furthercomprises an interface abstraction layer adapted to manage thecommunication between the abstraction layers. According to anotherembodiment of the invention, the interface abstraction layer is furtheradapted to insure standardized communication between the abstractionlayers. According to another embodiment of the invention, the interfaceabstraction layer includes a interface between the platform abstractionlayer and the VI abstraction layer. According to another embodiment ofthe invention, the interface abstraction layer includes a interfacebetween the platform abstraction layer and the system abstraction layer.

According to one embodiment of the present invention, the interfaceabstraction layer includes a interface between the platform abstractionlayer and the physical instrument abstraction layer. According toanother embodiment of the invention, the interface abstraction layerincludes a interface between a VI module and a PI module. According toanother embodiment of the invention, the interface abstraction layerincludes an interface between a SystemPI module and a VI module.According to another embodiment of the invention, the interfaceabstraction layer includes an interface between a SystemPI module and aPI module. According to another embodiment of the invention, theinterface abstraction layer includes a interface between the platformabstraction layer and the VI abstraction layer. According to anotherembodiment of the invention, the system further comprises a modulegeneration engine adapted to guide a user through the creation of one ofa PI module and a VI module so that the automated test system is capableincorporating new test hardware resources. According to anotherembodiment of the invention, the system further comprise an interfacegeneration engine adapted to guide a user through the creation of aninterface, wherein the interface will manage communication betweenmodules by standardizing the format of communication withoutconsideration of the hardware, software or platform being employed onthe automated test system.

According to one embodiment of the present invention, the system furthercomprises a rule checking engine adapted to verify the testfunctionality of a generated module and its generated interface.According to another embodiment of the invention, the system furthercomprises an installation module adapted to permit a user to install thegenerated module so that the test program could direct requests to thegenerated module and have test functions performed. According to anotherembodiment of the invention, the system further comprises aninstallation module adapted to permit a user to install the generatedinterface so that the test program may direct requests to the testhardware resources mapped to by the generated module and have testfunctions performed. According to one aspect of the present invention, asystem for performing a testing process is provided. The systemcomprises a test program that, when executed, performs a procedure onone or more test instruments, the one or more test instruments havingrespective one or more driver programs, and a virtual instrument entityadapted to execute the procedure on the one or more test instruments,wherein the virtual instrument entity accesses the one or more testinstruments through the respective one or more driver programs.According to another embodiment of the invention, the virtual instrumententity includes one or more functions. According to another embodimentof the invention, the test program is adapted to access the one or moretest instruments by accessing the one or more functions of the virtualinstrument. According to another embodiment of the invention, the testprogram is programmed to access the one or more instruments only throughthe virtual instrument. According to another embodiment of theinvention, the test program is programmed to access a system physicalinterface to gain access to tester resources. According to anotherembodiment of the invention, the virtual instrument entity isolates thetest program from programming interfaces specific to the one or moretest hardware. According to another embodiment of the invention, thevirtual instrument includes a virtual instrument programming interface.According to another embodiment of the invention, a change in the one ormore test instruments does not produce a corresponding change in thevirtual instrument programming interface.

According to one embodiment of the present invention, a change in thevirtual instrument entity does not produce a corresponding change in theone or more functions. According to another embodiment of the invention,a change in a physical tester resource does not produce a correspondingchange in the one or more functions. According to another embodiment ofthe invention, a change in a testing development platform does notrequire a change in the test platform. According to another embodimentof the invention, the one or more functions are loaded in a memorystructure of a computer system. According to another embodiment of theinvention, the change in the virtual instrument entity does not producea corresponding change in the memory structure of the computer system.According to another embodiment of the invention, the one or morefunctions are located in a first location in the memory structure of thecomputer system. According to another embodiment of the invention, thechange in the virtual instrument entity includes adding one or moreadditional functions. According to another embodiment of the invention,the change in the virtual instrument entity includes modifying at leastone of the one or more functions. According to another embodiment of theinvention, the one or more additional functions are added in a secondlocation following the first location in the memory structure of thecomputer system. According to another embodiment of the invention, theaddition of the one or more additional functions does not change thelocation of the one or more functions in the first location in thememory structure of the computer system. According to another embodimentof the invention, the memory structure of the computer system furthercomprises a vtable. According to another embodiment of the invention,the addition of the one or more additional functions does not change alocation of the one or more functions in the vtable. According toanother embodiment of the invention, the change in the virtualinstrument entity includes adding at least one modified function.

According to one embodiment of the present invention, the at least onemodified function is modified from the at least one of the one or morefunctions. According to another embodiment of the invention, the atleast one modified function is added in a second location following thefirst location in the memory structure of the computer system. Accordingto another embodiment of the invention, the addition of the at least onemodified function does not change the location of the one or morefunctions in the first location in the memory structure of the computersystem. According to another embodiment of the invention, the memorystructure of the computer system further comprises a vtable. Accordingto another embodiment of the invention, the addition of the at least onemodified function does not change a location of the one or morefunctions in the vtable.

According to another embodiment of the invention, the one or morefunctions is included in a base programming class of functions, and thebase programming class is inherited from an extended class of functionsincluding the one or more additional functions. According to anotherembodiment of the invention, the one or more functions is included in abase programming class of functions, and the base programming class isinherited from an extended class of functions including the at least onemodified function. According to another embodiment of the invention, thecomputer system includes a general-purpose computer system. According toanother embodiment of the invention, the one or more test instrumentsare coupled to one or more devices under test. According to anotherembodiment of the invention, at least one of the one or more testinstruments is programmed by the test program to apply a test signal toat least one of the one or more devices under test.

According to one aspect of the present invention a system for performinga testing process is provided. The system comprises one or more testinstruments, each having respective one or more driver programs andwherein at least one of the driver programs includes one or morefunctions, a test program that, when executed, performs a procedure onthe one or more test instruments, the test program accessing the one ormore test instruments through the one or more driver programs, and amemory structure, wherein the one or more functions of the at least oneof the driver programs are contained within a fixed location with thememory structure. According to one embodiment of the present invention,the memory structure is included in a memory of a computer system, andwherein the one or more functions are loaded in the memory of thecomputer system. According to another embodiment of the invention, achange in the at least one of the driver programs does not produce acorresponding change in the memory structure. According to anotherembodiment of the invention, the one or more functions are located in afirst location in the memory structure. According to another embodimentof the invention, the change in the at least one of the driver programsincludes adding one or more additional functions. According to anotherembodiment of the invention, the change in the at least one of thedriver programs includes modifying at least one of the one or morefunctions.

According to one embodiment of the present invention, the one or moreadditional functions are added in a second location following the firstlocation in the memory structure. According to another embodiment of theinvention, the addition of the one or more additional functions does notchange the location of the one or more functions in the first locationin the memory structure. According to another embodiment of theinvention, the memory structure further comprises a vtable. According toanother embodiment of the invention, the addition of the one or moreadditional functions does not change a location of the one or morefunctions in the vtable. According to another embodiment of theinvention, the change in the virtual instrument entity includes addingat least one modified function. According to another embodiment of theinvention, a change in a platform entity includes adding at least onemodified function. According to another embodiment of the invention, achange in a physical instrument driver includes adding at least onemodified function. According to another embodiment of the invention, theat least one modified function is modified from the at least one of theone or more functions.

According to one embodiment of the present invention, the at least onemodified function is added in a second location following the firstlocation in the memory structure. According to another embodiment of theinvention, the addition of the at least one modified function does notchange the location of the one or more functions in the first locationin the memory structure. According to another embodiment of theinvention, the memory structure further comprises a vtable. According toanother embodiment of the invention, the addition of the at least onemodified function does not change a location of the one or morefunctions in the vtable. According to another embodiment of theinvention, the one or more functions is included in a base programmingclass of functions, and the base programming class is inherited from anextended class of functions including the one or more additionalfunctions. According to another embodiment of the invention, the one ormore functions is included in a base programming class of functions, andthe base programming class is inherited from an extended class offunctions including the at least one modified function. According toanother embodiment of the invention, the computer system includes ageneral-purpose computer system. According to another embodiment of theinvention, the one or more test instruments are coupled to one or moredevices under test. According to another embodiment of the invention, atleast one of the one or more test instruments is programmed by the testprogram to apply a test signal to at least one of the one or moredevices under test.

According to one embodiment of the present invention, the system is partof an automated test system. According to another embodiment of theinvention, the system further comprises a virtual instrument entityadapted to execute the procedure on the one or more test instruments,wherein the virtual instrument entity accesses the one or more testinstruments through the respective one or more driver programs.According to another embodiment of the invention, the virtual instrumententity includes one or more functions. According to another embodimentof the invention, the test program is adapted to access the one or moretest instruments by accessing the one or more functions of the virtualinstrument. According to another embodiment of the invention, the testprogram is programmed to access the one or more instruments only throughthe virtual instrument. According to another embodiment of theinvention, the virtual instrument entity isolates the test program fromprogramming interfaces specific to the one or more test hardware.According to another embodiment of the invention, the virtual instrumentincludes a virtual instrument programming interface. According toanother embodiment of the invention, a change in the one or more testinstruments does not produce a corresponding change in the virtualinstrument programming interface. According to another embodiment of theinvention, a change in the virtual instrument entity does not produce acorresponding change in the one or more functions. According to anotherembodiment of the invention, the one or more functions are loaded in amemory structure of a computer system.

According to one embodiment of the present invention, the change in thevirtual instrument entity does not produce a corresponding change in thememory structure of the computer system. According to another embodimentof the invention, the one or more functions are located in a firstlocation in the memory structure of the computer system. According toanother embodiment of the invention, the change in the virtualinstrument entity includes adding one or more additional functions.According to another embodiment of the invention, the change in thevirtual instrument entity includes modifying at least one of the one ormore functions. According to another embodiment of the invention, theone or more additional functions are added in a second locationfollowing the first location in the memory structure of the computersystem. According to another embodiment of the invention, the additionof the one or more additional functions does not change the location ofthe one or more functions in the first location in the memory structureof the computer system. According to another embodiment of theinvention, the memory structure of the computer system further comprisesa vtable. According to another embodiment of the invention, the additionof the one or more additional functions does not change a location ofthe one or more functions in the vtable. According to another embodimentof the invention, the change in the virtual instrument entity includesadding at least one modified function. According to another embodimentof the invention, the at least one modified function is modified fromthe at least one of the one or more functions. According to anotherembodiment of the invention, the at least one modified function is addedin a second location following the first location in the memorystructure of the computer system.

According to one embodiment of the present invention, the addition ofthe at least one modified function does not change the location of theone or more functions in the first location in the memory structure ofthe computer system. According to another embodiment of the invention,the memory structure of the computer system further comprises a vtable.According to another embodiment of the invention, the addition of the atleast one modified function does not change a location of the one ormore functions in the vtable. According to another embodiment of theinvention, the change in the virtual instrument entity includes addingone or more additional functions. According to another embodiment of theinvention, the one or more functions is included in a base programmingclass of functions, and the base programming class is inherited from anextended class of functions including the one or more additionalfunctions. According to another embodiment of the invention, the one ormore functions is included in a base programming class of functions, andthe base programming class is inherited from an extended class offunctions including the at least one modified function. According toanother embodiment of the invention, the computer system includes ageneral-purpose computer system.

According to one aspect of the present invention, a system forperforming a testing process is provided. The system comprises a testprogram that, when executed, performs a procedure on a plurality of testinstruments, the one or more test instruments having respective one ormore driver programs, and a virtual multisite instrument entity adaptedto execute the procedure on the plurality of test instruments, whereinthe virtual instrument entity accesses the plurality of test instrumentsthrough the respective one or more driver programs, wherein the virtualmultisite instrument entity is adapted to execute the procedure on theplurality of test instruments transparently to the test program.According to one embodiment of the present invention, the virtualmultisite instrument includes functionality that controls a plurality ofinstrument sites. According to another embodiment of the invention, thevirtual multisite instrument entity includes one or more functions.According to another embodiment of the invention, the test program isadapted to access the plurality of instruments by accessing the one ormore functions of the virtual instrument. According to anotherembodiment of the invention, the test program is programmed to accessthe plurality of instruments only through the virtual instrument.According to another embodiment of the invention, the virtual multisiteinstrument isolates the test program from programming interfacesspecific to the plurality of instruments. According to anotherembodiment of the invention, the virtual multisite instrument includes avirtual multisite instrument programming interface.

According to one embodiment of the present invention, a change in atleast one of the plurality of test instruments does not produce acorresponding change in the virtual multisite instrument programminginterface. According to another embodiment of the invention, a change inthe virtual multisite instrument entity does not produce a correspondingchange in the one or more functions. According to another embodiment ofthe invention, the one or more functions are loaded in a memorystructure of a computer system. According to another embodiment of theinvention, the change in the virtual multisite instrument entity doesnot produce a corresponding change in the memory structure of thecomputer system. According to another embodiment of the invention, thevirtual multisite instrument entity is adapted to execute the proceduresubstantially in parallel on the plurality of test instruments.

According to one aspect of the present invention, a system forperforming a testing process is provided. The system comprises a testsystem, and at least one client computer coupled to the test system by acommunication network, wherein a user operating the client computer iscapable of executing a plurality of testing functions on the testsystem. According to one embodiment of the present invention, the systemfurther comprises a test program that, when executed, performs aprocedure on one or more test instruments, the one or more testinstruments having respective one or more driver programs. According toanother embodiment of the invention, the system further comprises aprocess that receives one or more requests from client computers throughthe communication network. According to another embodiment of theinvention, the at least one client computer includes a user interfacecomponent for accessing the test system. According to another embodimentof the invention, the user interface component is operated using abrowser program executing on the at least one client computer. Accordingto another embodiment of the invention, the test system furthercomprises a virtual multisite instrument entity adapted to execute theprocedure on the plurality of test instruments, wherein the virtualinstrument entity accesses the plurality of test instruments through therespective one or more driver programs, wherein the virtual multisiteinstrument entity is adapted to execute the procedure on the pluralityof test instruments transparently to the test program.

According to one embodiment of the present invention, the test systemfurther comprises a virtual instrument entity adapted to execute theprocedure on the one or more test instruments, wherein the virtualinstrument entity accesses the one or more test instruments through therespective one or more driver programs. According to another embodimentof the invention, the user interface component is configured based onthe user operating the client computer. According to another embodimentof the invention, the test system is adapted to store a plurality ofuser interfaces, and is adapted to provide at least one user interfaceto the user based on a user interface configuration associated with theuser. According to another embodiment of the invention, the virtualinstrument entity includes one or more functions. According to anotherembodiment of the invention, the test program is adapted to access theone or more test instruments by accessing the one or more functions ofthe virtual instrument. According to another embodiment of theinvention, the test program is programmed to access the one or moreinstruments only through the virtual instrument. According to anotherembodiment of the invention, the virtual instrument entity isolates thetest program from programming interfaces specific to the one or moretest hardware. According to another embodiment of the invention, thevirtual instrument includes a virtual instrument programming interface.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings are not intended to be drawn to scale. In thedrawings, each identical or nearly identical component that isillustrated in various figures is represented by a like numeral. Forpurposes of clarity, not every component may be labeled in everydrawing. In the drawings:

FIG. 1 shows a block diagram of an example conventional test systemarchitecture;

FIG. 2 shows a block diagram of another example conventional test systemarchitecture;

FIG. 3 shows a block diagram of a test system architecture according toone embodiment of the present invention;

FIG. 4 is a block diagram of a test system architecture according to oneembodiment of the present invention;

FIG. 5 is a block diagram of a test system architecture according toanother embodiment of the present invention;

FIG. 6A is a block diagram of a test system architecture according toanother embodiment of the present invention;

FIG. 6B is a block diagram of a test system architecture according toanother embodiment of the present invention;

FIG. 6C is a block diagram of a test system architecture according toanother embodiment of the present invention;

FIG. 6D is a block diagram of a test system architecture according toanother embodiment of the present invention;

FIG. 7 is a block diagram of a test system platform according to oneembodiment of the present invention;

FIG. 8 is a block diagram of a memory structure which may be used toimplement aspects of the present invention;

FIG. 9A is a block diagram of a test system architecture according toone embodiment of the present invention;

FIG. 9B is a block diagram of a memory structure according to oneembodiment of the present invention;

FIG. 9C is a block diagram of a memory structure according to anotherembodiment of the present invention;

FIG. 10 is a block diagram of a memory structure according to anotherembodiment of the present invention;

FIG. 11 is a block diagram of a test system architecture according toanother embodiment of the present invention;

FIG. 12 is a block diagram of a general-purpose computer system withwhich various aspects of the present invention may be practiced;

FIG. 13 is a block diagram of a test system test system architectureaccording to another embodiment of the present invention;

FIGS. 14A-B are diagrams of an example test system process according toone embodiment of the present invention;

FIG. 15 is a block diagram of an example alarm processing functionaccording to one embodiment of the present invention; and

FIG. 16 is a flow diagram of an example power initialize functionaccording to one embodiment of the present invention.

DETAILED DESCRIPTION

This invention is not limited in its application to the details ofconstruction and the arrangement of components set forth in thefollowing description or illustrated in the drawings. The invention iscapable of other embodiments and of being practiced or of being carriedout in various ways. Also, the phraseology and terminology used hereinis for the purpose of description and should not be regarded aslimiting. The use of “including,” “comprising,” or “having,”“containing,” “involving,” and variations thereof herein, is meant toencompass the items listed thereafter and equivalents thereof as well asadditional items.

A system and method is provided for performing processing in a testingsystem such as an ATE system. According to one aspect of the presentinvention, it is appreciated that conventional ATE systems are expensivedue primarily to the tight coupling between software and hardware.According to one aspect of the present invention, an improved method forperforming processing in an ATE system is provided which reduces theoverall cost of software. For instance, in an ATE system, it may beuseful to implement general-purpose computer systems, processors, and/orsoftware to reduce the cost of ownership and maintenance of suchsystems. In one example, various aspects of the invention may beembodied using off-the-shelf hardware and software (e.g., ageneral-purpose computer system, a commodity operating system (e.g.,Windows NT), etc.). Thus, the cost of developing an ATE system may be afraction of the cost of a specially-designed system usingspecifically-developed hardware and software. Thus, any method forreducing the overall cost of developing such a system is beneficial.

FIG. 1 shows a block diagram of an example conventional test systemarchitecture. For example, a conventional test system 100 generallyincludes one or more portions of test system software 101 along with anycorresponding test system hardware 102. The test system software mayinclude, for example, an operating system, which is generally aspecial-purpose operating system, one or more test system softwaredrivers (e.g., 104A-104B), and any testing applications developed fortesting one or more devices under test 106A-106B. In the case of anautomated test system 100, test system software 101 includes softwaredrivers (e.g., 104A) that are implementation-specific to the instrument(e.g., instrument 105A) to which the driver communicates. It followsthat the test system software 101 which communicates with one or moresoftware drivers is specifically-programmed to communicate with testsystem hardware 102 through such drivers (e.g., drivers 104A-104B).

According to one aspect of the present invention, it is appreciated thateach time a driver or its corresponding instrument is changed, theremust be a corresponding change to the driver and/or instrument. Becausethe test system software 101 such as, for instance, an operating system,test applications, or other software entities are written specificallyto communicate through such drivers, that a corresponding change in thedriver or hardware forces a change in the test system software 101.Because of this coupling, the test system software 101 must berecertified to work with software drivers and/or instruments which havebeen changed or added to test system 100. Further, a user 103 thatwrites test programs to work on test system 100 must perform additionaleffort to ensure that their test programs work with the changedenvironment.

FIG. 2 shows a block diagram of another example conventional test systemarchitecture that describes in more detail some of the problems in theconventional test programming environment. For example, a test system100 may include test system software 101 that comprises one or more testapplications 201A-201Z, each of which may have different versions havingvarying capabilities to work with one or more types of software andhardware. Similarly, there may be on a particular test system one ormore drivers (e.g., driver A 202A and driver B 203A) each of which mayhave one or more versions associated with it (e.g., driver A versions202A-202Z and driver B versions 203A-203Z). Further complicationincludes the test system operating system which itself may have one ormore versions 204A-204Z and which may be configured to work with anynumber of other software entities including drivers, applications, orother entities.

Similarly, test system hardware 102 may include one or more testhardware entities (e.g., test hardware A 205A, test hardware B 206A)that may include one or more versions (e.g., test hardware A versions205A-205Z, test hardware B versions 206A-206Z) that may have variousinterfaces and features. According to one aspect of the presentinvention, a modification in any one of these entities may causecommunication or function to perform differently and cause the overalltest system 100 to fail. In an ATE environment which requires that testprograms be performed in a deterministic way, such a non-deterministicoperation would not be desired.

According to one aspect of the present invention, a virtual instrumentis provided that isolates software applications from the underlyingdrivers and hardware (e.g., a test instrument) such that a change in thedriver or instrument does not affect the function of higher layersoftware such as an operating system, a testing application or othersoftware entity.

FIG. 3 shows a block diagram of a test system architecture according toone embodiment of the present invention that provides isolation betweenentities of a test system. An architecture 300 is provided wherein asoftware application 301, which may include, for example, a test systemapplication, an operating system, or any other type of software entitywhich is isolated from details of the physical instrument driver 303 andphysical instrument 304 by a virtual instrument 302.

Virtual instrument 302 may become, for example, an abstraction layerthat isolates the software application 301 and physical instrumentdriver 303 layers. Virtual instrument 302 may include, for example, codethat performs a mapping between an abstract virtual instrument interface(not shown) and functions and data existing within the physicalinstrument driver 303.

According to one embodiment of the present invention, the interfacepresented by the virtual instrument is a standard instrument interfacethat is independent of the underlying hardware. In one example system,the virtual instrument interface is written from the perspective offunctionality that a user would generally like to perform (for instance,generate a wave form for a device under test (DUT)). Generally, the useris not concerned with specifics of the hardware, and they are onlyconcerned with providing predictable stimuli and receiving predictableresults. Therefore, an interface is provided that presents to the userhardware-independent functional interfaces that can be accessed byusers' test programs in a standard way. Because of such astandardization of a virtual instrument, underlying physical instrumentdrivers and their corresponding instruments may be added or substitutedwithout affecting the operation of upper layer software applications301.

System Platform Architecture

Various aspects of the present invention may be implemented as a part ofan overall system architecture that permits developers, equipmentmanufacturers, test equipment companies and other types of users toprogram test programs used for testing various devices under test(DUTs).

In one specific architecture 400 as shown in FIG. 4, one or more testprograms 405A-405Z are developed by one or more users to operate onplatform software 401. In particular, test programs 405A-405Z may beprogrammed to access test hardware through a virtual multisiteinstrument layer 404A-404Z. Such virtual multi-site instruments arediscussed in more detail below, but in general are similar to virtualinstruments above in function in that they provide a virtual interfaceto one or more hardware devices. Such interfaces, according to oneembodiment, may be capable of presenting a hardware-independentinterface for performing test functions in an ATE system.

In one embodiment, the software interface to a physical piece ofhardware is implemented to what is referred to herein as a “PhysicalInstrument” (PI) module. Each piece of instrumentation hardware isaccompanied by an associated PI module that implements the basicfunctionality provided by the hardware. According to one embodiment, theuser's test program (TP) does not interact directly with a PI layer(403A-403Z) entities (e.g., a PI module). Rather, from the user testprogram's point of view, interaction with the test instrumentation ismade through what is referred to herein as a “Virtual MultisiteInstrument” (VMI) discussed further below. In one implementation, VMIsimplement their functionality by using one or more PIs, which in turn,access one or more instruments.

According to another embodiment of the present invention, what isreferred to herein as a Virtual Multisite Instrument (VMI) is providedthat facilitates management of multiple testing sites. In a traditionaltesting environment, it is appreciated that a site is managed as asingular entity in that if a particular testing site is configured, atest program is developed for the particular site, specific to theparticular testing hardware used. If multiple sites are needed toperform additional testing (e.g., to satisfy an increased testingcapacity), then additional test hardware configurations are purchased,and the test program is matriculated to the additional sites.

According to one aspect of the present invention, because details of theunderlying hardware is abstracted from test programs via an abstractionlayer (e.g., a virtual instrument layer), test programs can be managedindependent of test hardware, and the abstraction layer may be capableof managing the administration of a test program to multiple sites viathe abstraction layer. In one embodiment, the virtual instrument mayhave capability to map to multiple instrument sites. In this way, thetime needed to maintain and administer test programs to multiple sitesis reduced.

In one example, PIs can access test system resources through aspecially-defined PI referred to herein as the “System PI.” According toone embodiment, the System PI layer (e.g., layers 402A-402Z) provides aninterface that allows other PIs to use test system resources such as forexample, system memory, system triggers, and other resources. In anotherembodiment, the System PI may provide a communication interface to otherinstruments in a test system.

Practically, PIs may be implemented, for example, in a general purposecomputer system as a software library function (e.g., a Dynamic LinkedLibrary (DLL) as well-known in the Windows NT operating system).Appropriate PI modules may be loaded as needed, depending on thehardware present in the test system.

In one implementation, each PI is uniquely identified by a uniqueidentifier. In one example, the unique identifier may be unique acrossthe test system to uniquely identify a particular PI implementation.Such identification may be useful, for example, for communicating withPIs by other entities within the test system.

According to one embodiment, the system layer (e.g., as implemented by asystem driver) interfaces that allow for VMI and PI to be built upon thesystem layer. In another implementation, the VMI layer provides anabstraction layer from the hardware, which is encapsulated by the PI andSystem Driver software. In another embodiment, the system layer can alsoexpose functions to the test program for system specific resources(e.g., a calibration meter).

In another embodiment, the Test Program exposes any VMI functions to theuser—as a Virtual Instrument, the test program provides these functionsin a manner which captures what the user wants the test solution to looklike. The interfaces are guided by rules: add only, existing functionsdo not change in execution functionality or performance. Also, in oneimplementation each module performs version checking on module beinginteracted with so that adequate performance between modules is ensured.

Such rules may allow, for example, for complete forward-backwardcompatibility of the modules. That is, each module can be versionedindependently and all versions can work interchangeably. This permits,for example, test programs designed with a given version of VMIs can useany PI and System Driver (of the same type) version equal- to orgreater-than the versions used to when the test program was created andcompiled.

According to another embodiment, architecture 400 may include platformsoftware 401. In one embodiment, the functionality provided by aconventional computer operating system is abstracted to be part of theplatform software layer. According to one embodiment, the platform layeris abstracted so that almost any operating system can be used with anATE tester, such as general-purpose operating systems as discussedfurther below. In one embodiment, the platform software layer 401provides the basic functionality required by all the various componentsof the ATE tester to operate and communicate. In one embodiment, theWindows XP or Windows Vista operating systems may be used as the baseoperating system, which may govern basic functions required by thevarious ATE tester components. However, it should be appreciated thatother operating systems may be used.

FIG. 5 shows a more detailed example of a test system architecture 400according to one embodiment of the present invention. As discussed, anarchitecture 500 may include a platform software entity 501 thatperforms basic functions of the test system platform, and may besupported by a general purpose operating system such as, for example,the Windows XP or Windows Vista operating systems. In one embodiment ofthe present invention, a virtual representation of a particular testinstrument is abstracted so that the functions and functionalities ofany virtual instrument are segregated from the other abstraction layersof the test system. By isolating layers with well-defined programminginterfaces, as discussed above, maintaining interfaces between versionsof PIs, VMIs, etc., and their function locations in memory, testprograms developed on the platform continue to function even if elementsof the platform are modified.

According to another embodiment of the present invention, what isreferred to herein as a virtual multisite instrument (VMI) is providedthat facilitates management of multiple testing sites. In a traditionaltesting environment, it is appreciated that a site is managed as asingular entity in that if a particular testing site is configured, atest program is developed for the particular site, specific to theparticular testing hardware used. If multiple sites are needed toperform additional testing (e.g., to satisfy an increased testingcapacity), then additional test hardware configurations are purchased,and the test program is matriculated to the additional sites. Accordingto one aspect of the present invention, because details of theunderlying hardware is abstracted from test programs via an abstractionlayer (e.g., a virtual instrument layer), test programs can be managedindependent of test hardware, and the abstraction layer may be capableof managing the administration of a test program to multiple sites viathe abstraction layer. In one embodiment, the virtual instrument mayhave capability to map to multiple instrument sites. In this way, thetime needed to maintain and administer test programs to multiple sitesis reduced.

In architecture 500, one or more virtual multisite instruments (504A,504B) may be defined, and resources (e.g., one or more instruments orsites (505A-505C)) may be mapped to a virtual multisite instrument(VMI). Similar to virtual instruments, virtual multisite instrumentscommunicate with instruments 505A-505C through one or more physicalinstrument driver programs (e.g., PIs 503A-503C). Similar to a virtualinstrument, a virtual multisite instrument is not hardwareimplementation-specific, but rather, functionality is abstracted, andmapped to functions for particular hardware.

According to one embodiment, it should be appreciated that executing atest program on virtual instrument 504A, for example, the test programmay be executed at multiple instrument sites (instruments 505A and505C). A modification of the test program would, according to oneembodiment, cause the test program to be updated at multiple sites, as aresult of the abstraction of multiple sites into a single entity.Because of this capability, management of test programs on multiplesites is simplified.

According to one aspect of the present invention, the functionality ofan ATE tester are abstracted in a series of abstraction layers as shownin FIG. 4. According to one approach, the test program layer representsan abstraction of the functions and functionality employed by the ATEtester to interact with a user (typically through test programs). Inanother aspect of the present invention, the physical instrument layerrepresents an abstraction of the hardware implementation detailsnecessary to communicate with physical hardware instruments on the ATEtester. In another embodiment of the present invention, the functions ofan ATE tester are broken down into a virtual instrument layer, thatrepresents an abstraction of the functionality employed to map testrequests from the test program layer to the physical instrument layer; asystem layer, that represents an abstraction of the functionalityemployed by the physical instrument layer to communicate with thephysical hardware it represents; and a platform layer, that representsan abstraction of the function and functionalities employed to provide aplatform on which the other abstraction layers can operate. In anotherembodiment not shown in FIG. 4, the functions of an ATE tester arefurther abstracted into an interface layer, which represents anabstraction of the functionality employed to manage and standardizecommunication between the various abstraction layers. The layers shownin FIG. 4 will be discussed in greater detail below.

In a typical embodiment, an ATE tester is described with reference toabstraction layers that represent the functions of the ATE tester. Inone embodiment, the abstraction layers form the basis for the systemarchitecture. In one example, a test program forms a part of the testprogram layer. In another embodiment, a user interacts through the testprogram layer with the results of performed tests. In another example, auser may schedule test requests to be performed on specific instrumentsof the ATE tester, through the test program layer. It should be wellunderstood by those of skill in the art that multiple test programs caneasily be incorporated into the test program layer.

Platform Abstraction Layer

In another embodiment, the functionality provided by a conventionalcomputer operating system is abstracted to be part of the platformlayer. In one example, the platform layer is abstracted so that almostany operating system can be employed for use with an ATE tester.According to one aspect of the invention, the platform layer providesthe basic functionality employed by the various components of the ATEtester to operate and communicate. In the example shown by FIG. 4, theplatform layer forms the base of the architecture. In anotherembodiment, Windows XP is employed as the operating system that forms apart of the platform layer. In this instance, the operating systemmanages basic functions employed by the various ATE tester components.

In another embodiment, a library of C++ classes and C routines provideoperating system services to the various components of the ATE tester.According to one embodiment, the library of C++ classes and C routinesare part of the platform layer which allows for the use of almost anybase operating system as part of the platform layer. In anotherembodiment, Windows XP and INtime operating systems provide the basefunctionality employed by the ATE tester, although it should beappreciated that any real time operating system or general-purposeoperating system with real-time extensions may be used. Also, it shouldbe appreciated by one skilled in the art that many programming languagesand many class libraries can be employed to provide system services forthe various components of the ATE tester, and the platform layer is notrestricted to a library of C++ classes and C routines to provideoperating system services.

In one example, the platform layer has the capability of providingdeterministic function. In one embodiment of the invention,deterministic function is provided by employing an “off the shelf”operating system enhanced to be deterministic. For instance, Windows XPis employed as the off the shelf operating system, and is madedeterministic by employing real-time extensions. In another embodiment,the INtime operating system provides the real-time extensions that makeoperations deterministic, however, it should be appreciated that anyother real-time extensions may be used.

In a typical embodiment, the platform layer manages the operation of theother abstraction layers of the ATE tester.

Virtual Instrument Abstraction Layer

In one embodiment of the present invention, the functions of aparticular test instruments are abstracted into a virtual representationso that their functions are segregated from the other abstraction layersof the test system. For example, the functions of one instrument can berepresented in the virtual layer allowing other abstraction layers toaccess the instruments functionality through a virtualization. Accordingto aspect of the present invention, communication with thevirtualization can be standardized without being tied to any particularhardware implementation details. In a typical embodiment, the virtualinstrument layer is further abstracted into virtual instrument modules(“VI modules”) used to represent a virtualization of a group ofinstruments employed to test a device. According to one aspect of thepresent invention, a virtual instrument module can represent any numberof physical pieces of hardware. In one embodiment, the VI modulerepresents the functionality made available by the physical hardware ofthe ATE tester. In another embodiment, a user interfaces with a VImodule through test programs, with the VI module managing the functionsand function calls that cause any number of physical pieces of hardwareto perform their respective test functions.

According to one aspect of the invention, the virtual instrument layerdoes not contain any hardware specific implementation details. Rather,in one example, the virtual instrument layer contains the functionalityemployed to call another abstraction layer that does contain specifichardware implementation details. The separation described in the exampleallows for the easy incorporation of additional instruments into a VImodule. In another embodiment, when new hardware is added to a tester,the addition of new function calls that map to the abstraction layerthat contains the specific hardware implementation details enables thetester to employ the new functionality. In another aspect of the presentinvention, new functionality may be added by creating a new virtualinstrument module. It should be realized that by creating new virtualinstrument modules, adding new functionality has no impact on theexisting functions of the ATE tester. In one embodiment, virtual modulescan represent various versions of software, allowing software versioningto take place on an ATE tester while assuring that older versions andfunctionality are not impacted. In one embodiment, a virtual instrumentmodule is implemented as a dynamic link library. In yet anotherembodiment, the virtual instrument module may be implemented as aruntime system library (RSL).

Physical Instrument Abstraction Layer

In one embodiment, the physical instrument layer represents theabstraction of hardware specific implementation details of an ATE testsystem. In another embodiment, the physical instrument layer is furtherabstracted into physical instrument modules (“PI modules”). In oneexample, every piece of actual hardware is accompanied by a PI modulethat implements the basic functionality of that piece of hardware. Thefunctionality made available by a particular piece of hardware is oftenreferred to as a resource. In one embodiment consistent with theprinciples of the present invention, a PI module is implemented as adynamic link library. Alternatively, the PI module may be implemented asan RSL.

According to one aspect of the present invention, the virtual instrumentlayer calls the physical instrument layer to access the specifichardware implementation details of the hardware installed in the ATEtester. In one embodiment, this is accomplished by a VI module calling aPI module to access the hardware specific details that the PI modulerepresents. In one example, a PI module represents the specific hardwareimplementation details of a physical piece of hardware capable ofproviding clock synchronization signals to the ATE tester. In oneembodiment, a VI module manages the function calls to the PI module thatcause the physical piece of hardware to generate a clock synchronizationsignal.

The interaction between the various abstraction layers can be seen ingreater detail with reference to the exemplary FIGS. 6A and 6B. As theseillustrations show, the test program layer (User application/TestApplication) directs requests to VI modules of the virtual instrumentlayer (Virtual Instrument/VI), which in turn directs requests to PImodules of the physical instrument layer (Physical Instrument/PI).

FIG. 6A shows another example architecture showing an example testsystem architecture according to one embodiment of the presentinvention. A user application 601 accesses one or more VirtualInstruments (e.g., virtual instruments 602A-602N). As discussed, avirtual instrument may include any number of physical instruments (e.g.,physical instruments 603A-603N). This permits, for example, the testsystem to implement functions that would otherwise be dispersed in theindividual physical instruments.

In one implementation, the VMI has no specific knowledge of any actualhardware implementation. This knowledge resides with the “physicalinstrument module” (PI, e.g., physical instruments 603A-603N). Accordingto one example implementation, each piece of actual hardware isaccompanied by a PI module that implements all the basic functionalityof that hardware. The VMI uses the functionality provided by one or morePIs to implement the functionality that will be presented to the user.In other embodiments, the VMI may have some knowledge, depending on therequirements of the test system developers and/or application.

According to one embodiment, PI modules themselves do not communicatedirectly to the hardware but rather through a “System PI” entity (e.g.,system PI 604). System PI 604 implements functionality that allows thePI to communicate with the instruments that reside on the test head ofthe test system hardware. In another embodiment, a VMI may communicatedirectly to hardware through the System PI. In this embodiment, the VMImay also inform the PI of the communication so that the PI matches thehardware state as necessary.

It should be appreciated that FIGS. 6A-6B are presented by way ofillustration and not by limitation. FIG. 6A, also incorporates oneexample interaction between the physical instrument layer and the systemlayer to be discussed further below.

In one embodiment, as can be seen from FIGS. 6A-6B, a VI module canincorporate a number of PI modules, and even share PI modules. Accordingto one aspect of the present invention, by modularizing hardwareresources into PI modules the present invention provides flexibility andadaptability for any tester based on this model. According to anotheraspect of the invention, new PI modules can be easily programmed inresponse to additional testing needs, and old PI modules can beleveraged in the design and fabrication of new testers. In oneembodiment, a base class of function calls are provided that representfunctionality typically employed for the testing of any device. In oneembodiment, these base function calls can be incorporated into a PIModule and made available for use by test programs through a VI module.

System Abstraction Layer

According to one aspect of the present invention, the physicalinstrument layer does not communicate directly to physical pieces ofhardware they describe. In one embodiment, a PI module passes requests,function calls, and/or data to the system layer. According to one aspectof the invention, the system layer represents an abstraction of thefunctions and functionality that allows the PI layer to communicate withthe physical pieces of hardware (i.e. instruments) that are installed inthe ATE tester.

As can be seen from the example in FIG. 6C, a PI module of the physicalinstrument layer (shown as PI) communicates to the system layer (show asSystem PI) which maps calls to the physical hardware of the ATE tester.In one embodiment, the system layer includes a SystemPI module.According to another aspect of the present invention, the system layerrepresents an abstraction of the functionality employed to request andcommunicate information from other abstraction layers for reporting tothe platform layer.

Interfaces

According to another aspect of the present invention, the functionalitythat manages passing of function calls, requests, and data transfersbetween the abstraction layers is also abstracted in an interface layer.In one embodiment of the invention, the interface layer includes theabstraction of the functionality used to manage communication in betweenand amongst the various other abstraction layers. In one embodiment, theinterface layer manages the communication of function calls, thetransfer of data, and any other communications between modules containedwithin each abstraction layer. According to one aspect of the presentinvention, the interface layer insures that communications between thevarious modules of the ATE tester occur in an expected format. It shouldbe appreciated that by ensuring communications occur in an expectedformat, various modules will communicate in the same way regardless ofthe hardware implemented on any particular tester.

Virtual Machines

According to one aspect of the present invention, it is appreciated thatthere is a benefit from implementing various components of the testersystem on one or more virtual machines. Such virtual machines, as knownin the art, may be implemented as part of a virtual machine supported byone or more computer systems. Many different types of platforms supportvirtualization and virtual machines, and the invention is not limited toany particular one. One such type of system architecture that implementsvirtualization is shown by way of example in FIG. 6C.

According to one aspect of the present invention, it is appreciated thatby separating functionality of the user layer (e.g., the testerinterface) from the physical layer (e.g., the VMI and PIimplementations), that more generalized hardware and software may beused for user layer components, or any other type of component that doesnot require specialized hardware and software. Because the system may bearchitected in this way, the cost for producing such a tester can besignificantly reduced, as off-the-shelf hardware (e.g., PCs) andsoftware (e.g., OSs) may be used instead of specialized components.

Further, it is appreciated that by separating user layer components(including, for example, test programs), that the tester platform OS andassociated tester components may be modified without affecting userlayer components. That is, if the tester interfaces presented to theuser layer are maintained, the test program and other user layercomponents function consistently across changes. In this way, the userlayer components such as test programs may be ported more easily amongtest systems having different system components such as software andhardware. Further, test programs that are developed on such systems aremore useful over time, as they need not be reprogrammed and tested whenthe underlying hardware and software related to the test system needs tobe changed. To this end, more than one virtual machine may be provided,at least one for user-level components and another that executes atleast one component of the tester platform. As discussed previously, ina normal ATE implementation, the test system, test program and theassociated components are developed and maintained as a single entity,requiring retest and certification upon the occurrence of the slightestchanges. As a result, it is appreciated that normal ATE implementationsare less flexible, require greater effort to maintain, and are lessuseful as a result.

Versioning

FIG. 7 shows a block diagram of a test system platform according to oneembodiment of the present invention illustrating changes in physicalinstrument versions. For example, a user may develop a test application701 that is tailored to work with an example physical instrument version1.0 (item 702A). At some time later, a physical instrument version maybe made available that is different than an earlier version. Forinstance, physical instruments may have an additional capability thathas been added in a later version of the hardware. Similarly, a physicalinstrument driver may be provided that includes a different interface tothe new version of the physical instrument.

In one example, a physical instrument version 1.0 (702A) may, bydefault, produce an output voltage to a device under test of 5 volts. Ina physical instrument version Z (item 702Z), the default value of theoutput voltage may be different (e.g., 64 volts). Because of thischange, the test application 701 may not work in the manner indicated.Thus, according to one embodiment of the invention, a virtual instrumententity is provided that is independent of physical instrument versions,however, but is designed to support additional functionality as laterhardware and driver software becomes available.

Similarly, if a new version of a software platform becomes available, itmay be useful to use such a new version with one or more versions of aparticular physical instrument. Indeed, in some testing configurations,there may be a need to mix multiple versions of physical instruments andtest applications that are not configured to work together. According toone embodiment of the invention, a virtual instrument is provided thatdecouples test hardware from its associated software applications 301.

Maintaining Function References

According to one aspect of the present invention, a method for providingsoftware functions is provided that permits compatibility acrosssoftware and hardware versions. In one embodiment, functions of avirtual instrument are provided which remain unchanged between versions.More particularly, as functions are added to the virtual instrument, oldfunctions are maintained, and functionality is added to a predeterminedmemory structure. Functionality to software modules are added withoutchanging references to preexisting functions in memory. Because functionreferences are unchanged, additional functionality, when added to thememory structure does not break existing connections.

According to one embodiment of the present invention, a virtual functiontable (e.g., in the C++ programming language, the well-known virtualmethod table “vtable”)) is maintained for a virtual instrument. In oneembodiment, in one version of the virtual instrument vtable, a base setof functionalities included having a defined location in the vtable. Ina subsequent version of the virtual instrument table, additionalfunctions are added to the vtable, while maintaining the same locationof the vtable for the base set of functionality. In this way, functionsand their connections to other software entities are maintained withoutbreaking existing programs when additional functions are added. Forinstance, a base vtable may be followed by a derived vtable includingthe additional functionality. Although a vtable may be used as discussedbelow to maintain function references, it should be appreciated thatother methods may be used to ensure function references are not broken(e.g., a function arbitration or tracking function).

FIG. 8 shows a block diagram of a vtable memory structure which may beused to implement various aspects of the present invention. As shown,vtable 800 includes one or more methods 801A-801E which correspond tofunctions associated with particular instrument driver. In aconventional scenario when a particular function (e.g., method E (801E))is modified, the behavior of the method changes, and thus any hardwareor software that communicates using the function does not perform in themanner originally planned for in the earlier version. For example, ifmethod E is called incorrectly, includes different default values, orreturns data in a different format, the calling function will performdifferently than expected. According to one aspect of the presentinvention, a memory structure is provided that permits software featuresto be added without breaking existing connections.

Example Versioning Architecture

FIG. 9A shows one architecture 900 according to one embodiment of thepresent invention. In particular, application 901 may use one or morevirtual instruments, each of which may have varying feature sets thatfacilitates software compatibility among software modules of a testingsystem. For instance, a virtual instrument V.1.0 (Item 902A) may beprovided that is mapped to one or more physical instrument (PI) drivers.That is, a particular virtual instrument may be permitted to access oneor more versions of a physical instrument driver.

Conventionally, when an instrument is added to a system, the driverassociated with that new instrument replaces previous versions of theinstrument driver. According to one aspect of the present invention, amethod is provided wherein different version instruments may be usedwithin the same test system, and are accessed via a single virtualinstrument.

In one example, virtual instrument v.1.0 (item 902A) may be configuredto communicate to instrument v.1.0 (item 904A) via physical instrumentdriver v.1.0 (item 903A) having a function set of elements [a, b, c, d,e]. Further, virtual instrument v.1.0 (item 902A) may be capable ofcommunicating to instrument v.y (item 904Z) having functions set [a, b,c, d, e′, f, g] using physical instrument driver v.y (item 903Z).Therefore, an application 901 may be capable, depending on theapplication, may use any version of an instrument and its associateddriver without conflict.

FIG. 9B shows a block diagram of a memory structure according to oneembodiment of the present invention. As discussed according to oneaspect of the present invention, it may be beneficial to introduceadditional hardware that may include one or more modified functions overprevious functions or take advantage of additional functionality innearly-introduced hardware and software. As shown in FIG. 9B, a vtable901 associated with a physical instrument version v.1.0 includes one ormore functions [a, b, c, d, e]. At a later point, a later version of aphysical instrument is made available having a corresponding vtable 912including functions set [a, b, c, d, e′, f, g].

According to one aspect of the invention, a further version of thevtable associated with a physical instrument includes maintaining thesame function references from previous versions to ensure that softwarethat calls a particular function can locate that same function in thesame location. So, for example, the function A (item 913A) is mapped tofunction A of the next version of the vtable, and is located in the samememory location. Further, in another example wherein a particularfunction is modified in the later version, the existing function (e.g.,function E (item 914A)) is maintained in the same memory location in thelater-version of the vtable. In this way, a newer version of a physicalinstrument may be added to the system without effecting existingsoftware and applications that access the later version.

According to one aspect of the present invention, modified and/or addedfunctionality is added to the following portions of the vtable so thatthe connections between old applications and newer versions of thephysical instrument are maintained. According to one embodiment, thesemodified or added functions are added after previous versionsfunctionality. For example, as shown in FIG. 9B, a modified function 915e′ is added after the original function 914B e. Further, as shown inFIG. 9B, additional functions f and g are added functions 916 which canbe added after the base functions a through e. In this manner,functionality, whether changed or added, does not disturb existingreferences within the vtable. Because of this, existing connectionsbetween old applications and new versions of the physical instrument arenot broken.

Further, it should be appreciated that a later version of a PI vtablemay be used to access the same or previous versions of a particularinstrument hardware by adhering to the conventions discussed above.

FIG. 10 shows a block diagram of a memory structure according to anotherembodiment of the present invention showing how backwards compatibilityis maintained using the program and conventions as described above. Inparticular, a version 2.0 of the PI vtable (item 1001) includes a numberof methods including the set [a, b, c, d, e, e′, f, g]. Because thelater version of the vtable includes all of the functionality fromprevious versions of the PI, and their locations within the PI vtableare maintained, the later-version PI is capable of communicating withcurrent and earlier versions of the instrument hardware. For instance,the method a, which is used by instrument version 1.0 (item 1002) andinstrument version 2.0 (item 1003) are the same, and backwardcompatibility between the version 2.0 PI (item 1001) and previousversions of the instrument are maintained.

In the case where a new method is added in a later version of aninstrument (e.g., instrument version 2.0 (item 1003)), according to oneembodiment, that additional functionality is added to the end of the newversion of the vtable. Therefore, in the example as shown in FIG. 10,previously-defined method e maps to instrument version 1.0 (item 1002)without breaking the communication between the new version of the PIvtable, while still supporting a modified method e′ used forcommunicating with version 2.0 of the instrument (item 1003). As long asthe VMI knows what to call (e.g., what version of PI to call (e.g.,version number identified in abstract class)), then the connectionbetween the elements will not break.

Such backward compatibility can be performed, for example, by providingan abstract class which is inherited by later classes that include themodified or added functionality. In this way, vtables are constructedsuch that the base data structure and associated methods include thesame vtable function locations.

Therefore, in summary, for each successive revision of the software astandard vtable structure may be used which maintains the structure of aprevious versions vtable. Because the structure is maintained, theapplications or other programs that use the standard vtable structurecan access newer and older methods as well as newer or older versions ofhardware. However, it should be appreciated that other methods may beused for maintaining function references, and that a vtable need not beused.

Similarly, if a virtual instrument is revised to take advantage of newerfunctions, the same programming rules may be used to ensure that olderversions of software (and therefore, hardware) can communicate with thevirtual instrument version. For example, if a virtual instrument versionX (item 902Z) is introduced, the virtual instrument version X willmaintain the same vtable structure as previous versions, and inaddition, may include additional functionality within the virtualinstrument. Thus, certain functions provided in various versions of avirtual instrument may have forward and backward compatibility betweendifferent versions of physical interface drivers.

As shown with particularity in FIG. 9C, a VI version 1.0 vtable (item921) may be capable of accessing certain functions provided by variousversions of a physical interface driver. A particular function createdin the VI may call one or more functions in the PI that perform thehigher-layer function of the VI. As shown, functions A-E (items925A-925E) use functions a-e in either PI version 1.0 (item 922) or PIversion 2.0 (item 924). In this way, a physical instrument driver may bereplaced that is compatible with the virtual instrument methods, asfunction references are maintained within the vtable structure. Althougha one-to-one mapping is shown between functions of the VI and PI, itshould be appreciated that there may be other calling patterns betweenfunctions, and the shown mapping is provided to illustrate variousaspects of the present invention and is provided for example only.

It can be shown that a later version of a vtable associated with avirtual instrument is compatible with both earlier versions of aphysical instrument driver as well as later versions of a physicalinstrument driver. For instance, as shown in FIG. 9C, a modified methodE (item 926A) is added to the virtual instrument vtable whichcorresponds to e′ function of version 2.0 of the physical instrumentdriver (item 924). For example, a new version of a VI may be providedthat takes advantage of additional functionality in a later version of aphysical instrument driver.

Further, in much the same way as changes made to a physical instrumentdriver, modified and/or additional functionality may be added to the endof the vtable structure such that original functionality is notmodified. Thus, an older version of a physical instrument driver (e.g.,PI version 1.0) is capable of working with a later version of the VI(e.g., version 2.0). That is, a later version of the VI may communicatewith an earlier version of the PI. In this way, both forward andbackward compatibility is maintained between software entities withinthe ATE system.

Programming Example

Instrument independence is an important feature of a test systemarchitecture, according to one embodiment of the present invention. Thisfeature allows independent improvements or modifications of eachinstrument without the need for coordinated simultaneous upgrades. Inorder to maintain this independence, the test system provides a systemdriver function via the system PI to manage the synchronization andtriggering subsystem. In this scheme, the system PI acts as a mediatorbetween instruments. The system PI manages the use and availability ofsignal lines, sets trigger connections and modes, and keeps delayinformation and does other housekeeping functions.

Starting with the user program or application (e.g., 901), the userprogram calls functions of the virtual multisite instruments (VMIs)which in turn call functions of the instrument physical drivers (orPIs). When PIs are created, they are provided access to the system PIfor system level functions, calibration and the use of system resources(e.g., memory, trigger subsystem, etc.). The following discusses apractical example of a user program that accesses hardware through thetest architecture shown in FIG. 10.

Consider a digital instrument resource mapped to a VMI called “Control”that generates a pulse when a pattern is run. The digital instrument isconnected to a V/I resource which is mapped to a VMI called ‘Vcc’ thatuses the instrument as a measurement strobe to measure the Idd currentat that point in the pattern. The test code may look something similarto:

. . . Control->ConnectTrigger(9,’Iddmeas’); Vcc->SetModeIMeasure(100ma);Vcc->ConnectMeasStrobe(‘Iddmeas’); Control->RunPattern(‘mypat’);Wait(100ms); Vcc->GetMeas(&Idd); . . .

In the first line, Control->ConnectTrigger(9,‘Iddmeas’); the VMI firstmakes a call to the resource mapped to it (the resource being in the PI)and the PI requests a connection of a specific Trigger Line to a SignalLine via the system PI for each site named ‘Iddmeas[site]’. If they donot and sufficient signal lines are available, then the signal lines arereserved (by name) and the connection counter is set to 1, if the signallines already exist the connection counter is incremented. In the eventthat there are insufficient signal lines available, an alarm may begenerated. Upon successful reservation of signal lines, the VMI theninstructs the Instrument PI(s) for each site to connect pattern bit 9 tothe signal ‘Iddmeas[site]’.

Each PI checks for an available trigger line and make the connection onboard. The PI then requests the System PI to make the connection of itschosen trigger line to the signal named ‘Iddmeas[site]’. The InstrumentPI does this by sending information to the System PI as to its location,trigger line selected and direction of the connection (in this caseAsynchronous Dive) and the signal to be connected to. The system PI setsthe appropriate connection in the cross-point function and set the modefor the selected trigger line. Now we have pattern bit 9 driving thesignal line named ‘Iddmeas[site]’.

In the second line, the VMI called Vcc is set to current measure mode onthe 100 ma range. In the third line, the VMI called Vcc is instructed toset the measurement strobe to trigger mode and connect the strobe to thesignal named ‘Iddmeas’ in receive mode. This may be accomplished, forexample, by having the Vcc VMI making a call to the System PI to reservethe Signal lines but since they were already reserved, the connectioncounter may be simply incremented. Then the Vcc VMI calls the individualinstrument PIs to make the connection.

The VMI instruments makes the connection of the strobe to an availabletrigger line on-board and request the System PI to connect the selectedtrigger line to ‘Iddmeas’ in Asynchronous Receive mode.

Next, the pattern is run and the measurement is stored on the board.This may be followed by a delay and then the measurement(s) areretrieved. The connections persist and can be used in subsequent testsso it is not necessary to re-program the connection if the connection isneeded again. A situation may arise where there are no longer enoughsignal lines available for use in subsequent tests. In this case, aDisconnect function may be used to free up signal lines that are nolonger needed. The system PI may maintain a count of connections and anydisconnect function call from a VMI will be honored if the count iszero. To free up ‘Iddmeas’ in the example, the following lines may beadded:

-   -   Control->DisconnectTrigger(9,‘Iddmeas’);    -   Vcc->DisconnectMeasStrobe(‘Iddmeas’);

In the first line above, the Digital VMI ‘Control’, may instruct theinstrument PIs to disconnect, The PIs request the disconnect from theSystem PI, Then the Control VMI requests the disconnect of the Signalnamed ‘Iddmeas’. The system PI decrements the connection counter butdoes not free up the signal lines because a connection still exists. Inthe second line above, the Vcc VMI similarly instructs the instrumentPIs to disconnect, then request a disconnect from the system PI. In thisinstance the System PI decrements the connection counter to zero andde-allocate the signal line for later use.

According to one embodiment, the System PI manages the resources (signallines) in a robust way. For example, all signal lines may bede-allocated at program load and at start of test. Also, since toolsmight be able to control connection state and users may quit atbreakpoints etc., signal lines should not be locked out in error.

By use of this example, a basic connection scheme is performed betweentwo instruments. As can be seen, the instrument function in no waydepends on the implementation of the function in the instrument to whichit is connecting. A drawback of this scheme is that there are two linesof user code needed to make a connection. However, the architectureprovides the ability for multiple instruments to connect to a singlesource.

FIG. 11 shows another example of a test system architecture which may beused to implement various aspects of the present invention.Deterministic operation is one basic requirement to achieve a high levelof repeatability in test applications. By reducing the jitter associatedwith the execution time of individual tests in a test application,measurements made across multiple devices will be much more consistentand accurate. The ATE industry has solved this problem by usingdedicated processors running real-time operating systems to executeindividual tests. The drawback with this approach is that deterministicoperation is achieved at a very high cost.

This creates a problem for low-cost test systems where usually only asingle processor is available to control all tasks relating to a testenvironment (e.g., user-interface, datalogging, test execution, etc.).To complicate matters even further, the availability of real-timeoperating systems (RTOSs) for low-cost platforms is relatively small andthese operating systems are not tailored to provide users with friendlyand “nice-looking” user-interfaces. Usually the interface provided bythese RTOSs is text-based and generally based on very cryptic commandsfor the lay user.

FIG. 11 shows an example architecture that includes both real-time andnon-real time components. For example, the architecture may include agraphical user interface 1101 which is used by the user to perform andmaintain test programs. Further, the architecture may include a data logprocess 1102 that stores test results retrieved from devices under test(DUTs). Further, the system may include a non-real-time function 1103that performs flow control relating to executed test procedures.Further, the architecture may perform any number of non-realtime-tasks1104 relating to testing, such as reporting, alarms, or other tasks.

In one embodiment of the present invention, real-time and non-real-timecomponents may be implemented on separate virtual machines. Theseseparate virtual machines may be, for example, executed on the same ordifferent processors as is known in the art. The virtual machines mayperform inter-virtual machine communication to implement variousdistributed functionality. According to one aspect, by implementingnon-real-time components on a separate system entity (e.g., a separatevirtual machine), the cost of such a system may be reduced, asoff-the-shelf hardware and software may be used to implement suchnon-real-time components.

Further, the architecture provides real-time processes for performingfunctions relating to testing one or more DUTs. For instance, a testexecution control component 1106 may be provided that governs theexecution of test functions on the one or more DUTs. The system may havedefined one or more virtual multisite instruments (e.g., VMIs1108A-1108C) that can be used to implement one or more test programsprovided by a user. Also, the architecture may include other ancillaryreal-time tasks 1107 that are performed to support the testingprocedures. Such tasks may include, for example, signaling or othertime-dependent tasks.

To facilitate communication between real and non-real-time processes, aninter-OS communication area 1105 (or an inter-virtual machinecommunication area in the case of using separate virtual machines) maybe provided which allows real-time tasks to communicate with and accessresources in the non-real-time domain.

Although the Windows XP operating system has a well-known graphical userinterface, the Windows XP operating system is not a real-time operatingsystem. This basically means that the Windows XP operating system cannotguarantee that a particular operating system request will be serviced ina particular amount of time, or that tasks running under the operatingsystem are guaranteed to execute in a predetermined period of time.According to one embodiment, the Windows XP operating system may bemodified to allow the operating system (or any other operating system)to provide real-time capabilities.

According to one embodiment of the present invention, Tenasys real timeextensions (INtime extensions product) may be used, but it should beappreciated that other types of extensions or any other real-timeoperating system (RTOS) may be used. Tenasys offers a solution thatprovides the ability to run two completely different operating systemsin a single processor while allowing communication between the two OSs.Tenasys technology that allows both operating systems to run on an x86platform without interference. This technology also guarantees thatfailures (even catastrophic failures) in one environment do not causeany side effects on the other environment. This allows for a very highdegree of reliability.

The INtime product provides a real-time environment in which the WindowsNT operating system itself is a low-priority task. This way allreal-time tasks take precedence over Windows NT operating system so itis possible to guarantee consistent execution times regardless of anyactivity in the Windows environment. According to one embodiment, thetest system architecture relies on a real-time environment where alltime critical tasks are executed and a non-real-time environment whererelatively low-priority tasks will execute. Both of these operatingsystem environments would share a single processor system andcommunicate with each other when necessary.

According to one embodiment of the present invention, a testarchitecture may be adapted to perform deterministic processing asdiscussed in U.S. patent application Ser. No. 11/218,915 filed Sep. 2,2005, entitled “SYSTEM AND METHOD FOR PERFORMING DETERMINISTICPROCESSING”, the contents of which are incorporated herein by reference.However, it should be appreciated that other operating systems may beused with real-time capabilities, and the invention is not limited toany particular type of operating system.

General Purpose Computer System

Various embodiments according to the present invention may beimplemented on one or more computer systems. These computer systems maybe, for example, general-purpose computers such as those based on IntelPENTIUM-type processor, Motorola PowerPC, AMD Athlon or Turion, SunUltraSPARC, Hewlett-Packard PA-RISC processors, or any other type ofprocessor. It should be appreciated that one or more of any typecomputer system may be used to perform processing according to variousembodiments of the invention. Further, the system may be located on asingle computer or may be distributed among a plurality of computersattached by a communications network.

A general-purpose computer system according to one embodiment of theinvention is configured to perform any of the described functions,including but not limited to, performing processing associated with atest program. It should be appreciated that the system may perform otherfunctions, and the invention is not limited to having any particularfunction or set of functions.

FIG. 12 shows a block diagram of a general purpose computer and networksystem in which various aspects of the present invention may bepracticed. For example, various aspects of the invention may beimplemented as specialized software executing in one or more computersystems including general-purpose computer system 1201 shown in FIG. 12.Computer system 1201 may include a processor 1204 connected to one ormore memory devices 1205, such as a disk drive, memory, or other devicefor storing data. Memory 1205 is typically used for storing programs anddata during operation of the computer system 1201. Components ofcomputer system 1201 may be coupled by an interconnection mechanism suchas network 1210, which may include one or more busses (e.g., betweencomponents that are integrated within a same machine) and/or a network(e.g., between components that reside on separate discrete machines).The interconnection mechanism enables communications (e.g., data,instructions) to be exchanged between system components of system 1201.

Computer system 1201 also includes one or more input/output (I/O)devices 1206, for example, a keyboard, mouse, trackball, microphone,touch screen, a printing device, display screen, speaker, etc. Inaddition, computer system 1201 may contain one or more interfaces (e.g.,network communication device 1208) that connect computer system 1201 toa communication network (in addition or as an alternative to the network1210.

The storage system 1209, typically includes a computer readable andwriteable nonvolatile recording medium in which signals are stored thatdefine a program to be executed by the processor or information storedon or in the medium to be processed by the program. The medium may, forexample, be a disk or flash memory. Typically, in operation, theprocessor causes data to be read from the nonvolatile recording mediuminto another memory that allows for faster access to the information bythe processor than does the medium. This memory is typically a volatile,random access memory such as a dynamic random access memory (DRAM) orstatic memory (SRAM). The memory may be located in storage system 1209,as shown, or in memory system 105. The processor 104 generallymanipulates the data within the integrated circuit memory 104, and thencopies the data to the medium associated with storage 1209 afterprocessing is completed. A variety of mechanisms are known for managingdata movement between the medium and integrated circuit memory elementand the invention is not limited thereto. The invention is not limitedto a particular memory system or storage system.

The computer system may include specially-programmed, special-purposehardware, for example, an application-specific integrated circuit(ASIC). Aspects of the invention may be implemented in software,hardware or firmware, or any combination thereof. Further, such methods,acts, systems, system elements and components thereof may be implementedas part of the computer system described above or as an independentcomponent.

Although computer system 1201 is shown by way of example as one type ofcomputer system upon which various aspects of the invention may bepracticed, it should be appreciated that aspects of the invention arenot limited to being implemented on the computer system as shown in FIG.12. Various aspects of the invention may be practiced on one or morecomputers having a different architectures or components that that shownin FIG. 12.

Computer system 1201 may be a general-purpose computer system that isprogrammable using a high-level computer programming language. Computersystem 1201 may be also implemented using specially programmed, specialpurpose hardware. In computer system 1201, processor 1204 is typically acommercially available processor such as the well-known Pentium classprocessor available from the Intel Corporation. Many other processorsare available.

Such a processor usually executes an operating system which may be, forexample, the Windows-based operating systems (e.g., Windows NT, Windows2000 (Windows ME), Windows XP, Windows Vista operating systems)available from the Microsoft Corporation, MAC OS System X operatingsystem available from Apple Computer, the Solaris operating systemavailable from Sun Microsystems, UNIX operating systems available fromvarious sources, INtime and Tenasys as mentioned above, among others.Many other operating systems may be used, and the invention is notlimited to any particular operating system or operating systemextensions to perform any real-time or non-real-time functions accordingto various embodiments.

The processor and operating system together define a computer platformfor which application programs in high-level programming languages arewritten. It should be understood that the invention is not limited to aparticular computer system platform, processor, operating system, ornetwork, unless specified by one or more claims. Also, it should beapparent to those skilled in the art that the present invention is notlimited to a specific programming language or computer system. Further,it should be appreciated that other appropriate programming languagesand other appropriate computer systems could also be used.

One or more portions of the computer system may be distributed acrossone or more computer systems coupled to a communications network. Thesecomputer systems also may be general-purpose computer systems. Forexample, various aspects of the invention may be distributed among oneor more computer systems (e.g., servers) configured to provide a serviceto one or more client computers, or to perform an overall task as partof a distributed system. For example, various aspects of the inventionmay be performed on a client-server or multi-tier system that includescomponents distributed among one or more server systems that performvarious functions according to various embodiments of the invention.These components may be executable, intermediate (e.g., IL) orinterpreted (e.g., Java) code which communicate over a communicationnetwork (e.g., the Internet) using a communication protocol (e.g.,TCP/IP).

It should be appreciated that the invention is not limited to executingon any particular system or group of systems. Also, it should beappreciated that the invention is not limited to any particulardistributed architecture, network, or communication protocol.

Various embodiments of the present invention may be programmed using anobject-oriented programming language, such as SmallTalk, Java, C++, Ada,or C# (C-Sharp). Other object-oriented programming languages may also beused. Alternatively, functional, scripting, assembly language, and/orlogical programming languages may be used. Various aspects of theinvention may be implemented in a non-programmed environment (e.g.,documents created in HTML, XML or other format that, when viewed in awindow of a browser program, render aspects of a graphical-userinterface (GUI) or perform other functions). Various aspects of theinvention may be implemented as programmed or non-programmed elements,or any combination thereof.

Various aspects of this system can be implemented by one or more systemswithin system 100. For instance, the system may be a single ormultiprocessor system. In one example, the system includes softwareprocesses executing on a system such as a personal computer (PC). Such asystem, for example, may permit the user to perform one or morefunctions in a test system that tests a device under test (DUT). Suchsystems may include, for example, test systems, control systems, amongothers.

Example Client-Server Architecture

According to another aspect of the present invention, it is appreciatedthat test programs software is used by different types of user—someusers develop test applications, and others use the developedapplications for the administration and management of test processes.However, these separate types of users may need to use a specific userinterface (UI), depending on what functions are performed. It isappreciated that multiple types of testers have different userinterfaces, forcing the user to understand the specific type ofinterface necessary to run the equipment. Also, it is appreciated thatin the ATE industry, the application and drivers are tightly coupled,and the user interfaces are tied to the system software. According toone aspect of the present invention, a standard user interface may beused to access multiple tester types, reducing the amount of trainingnecessary for the user. To further reduce the amount of trainingrequired, a user-specific interface is provided that allows the user toperform testing functions related to their role.

Further, according to another aspect of the present invention, a testingarchitecture is provided that permits a user to perform testingfunctions from any location. In one specific implementation, the userinterface is accessed through a browser program, and a user may performtesting functions from any location coupled to a testing system througha communications network. In a traditional environment, the UI isnormally tied to the machine, however, if the UI is made available overa network, the user can perform testing from another location.

FIG. 13 shows an architecture diagram of an example system 1300according to one embodiment of the invention that includes a server thatexecutes test functions, and one or more client systems that render userinterfaces used to perform test functions. It should appreciated thatFIG. 13 is used for illustration purposes only, and that otherarchitectures may be used to facilitate one or more aspects of thepresent invention.

As shown in FIG. 13, a computer system 200 (e.g., a general-purposecomputer system as described above with reference to FIG. 12) may beused to implement a test system. Computer system 1301 may include one ormore software processes 1305 that perform test system functions,database functions, and interface functions as discussed below.According to one embodiment of the present invention, system 1301 may bea general-purpose computer system as discussed above with reference toFIG. 12. To this end, system 1301 may include an operating system, oneor more processors, and one or more I/O components.

According to one embodiment, system 1301 permits one or more clientsystems (e.g., systems 1307A-1307D) and their associated users (e.g.,users 1308A-1308D) to access test functions. According to oneembodiment, the test system 1301 and its associated hardware andsoftware are communicated with via one or more communication networks1304. Network 1304 may include, for instance, the Internet, a corporateenterprise network or other communication network type. Notably, userscan access test system functions at disparate locations throughcommunication network 1304.

In one embodiment, the test system user interface is a web-basedinterface, capable of being downloaded and viewed over a communicationnetwork. In one embodiment, a client (e.g., client 1307D) includes abrowser program (e.g., the Microsoft Internet Explorer browser program).The user may log into test system 1301, and system 1301 may provide oneor more software programs or components 1303 that may be used by aclient to access test system functions. According to one embodiment,test system functions are performed using the well known Windows formsinterface available from the Microsoft Corporation, and may beaccessible through a browser program (e.g., 1309). Indeed, the clientmay download and store any application program 1310 software and/ordatabase elements (e.g., elements stored in database 1311) to render theuser interfaces discussed. However, although Windows forms may be used,it should be appreciated that any type of software and/or communicationmethods may be used (e.g., CGI, Perl, XML, etc.), and the invention isnot limited to any particular method.

Notably, the user can, from any web-enabled client, perform testfunctions. Using web services, for example, a user can control anytester from any location as long as the user has a connection to thetest system 1301. Conventionally, user interfaces are tied to and arespecific to the testing hardware, and thus are executed locally to thetest equipment. According to one embodiment of the present invention, auser logs into the test system 1301 through a communications network(e.g., the Internet).

Further, according to another embodiment, each user is presented theirown set of GUIs to control testing. In the case where users performdifferent functions (programming, maintenance, etc.), the test system1301 may store different UIs (e.g., as an entry 1306 in database 1302),and depending on the user that logs in, different UIs may be presentedto that user. The UIs may include one or more programs (e.g.,application program 1310) having one or more locally-stored components.Further, the UIs may include one or more databases in which to store UIconfiguration data. Thus, the user can view custom UIs at any locationhaving network connectivity, and the custom UIs are tailored to suit theparticular role of the user.

Processes in the ATE Tester

In one embodiment of the present invention, the PowerPoll process, 1400,as shown in FIGS. 14A-B, illustrates the interaction between some of themodules within the abstraction layer architecture. The following is anexample process that may be performed, for example, using the processflow, 1400, described with respect to FIG. 15. It should be appreciatedthat the process discussed below is made by way of example only and notby limitation.

The PowerPoll process, 1400, is typically initiated in the platformlayer by the expiration of a timer at 1402. Optionally, the PowerPollprocess may also check to see if an end of time (EOT) event has occurredor if a program has reached a break point. If the power polling timerhas not expired 1404 (FALSE), main thread execution continues at 1406.If the power polling timer has expired, 1404 (TRUE), the platform layerpasses a call to the system layer, including two platform statevariables “System PowerState” and “System Power Interrupted.” Inresponse the system layer through a SystemPI Module calls the UpdateSystemPowerStatus function, at 1408. In one embodiment, after the entiredata flow has been completed the SystemPI will return 2 bits of data tothe platform layer; Bit 1: reflecting Power Interrupted & Bit 0:reflecting PowerState. By this abstraction, the platform does not needto know how to actually check the power (e.g., determine the state of apower switch, determine the existence of voltage, etc.), but rather, theSystemPI performs this checking function.

The process flow optionally continues by determining if the platformstate variable is at “ProgramAtBreakPoint,” (not shown), if not adispatcher control component reads the mailbox and clears it at step1410. The dispatcher control component takes the latest configuration(if any) and compares that configuration to the current configuration,at step 1410. Upon determining a different configuration exists 1412(TRUE), a check is done to determine if PI modules were deleted at 1414,if PI modules were not deleted, 1414 (FALSE) the new PI modules areloaded at 1420, where PI modules were deleted 1414 (TRUE) PowerOnInitfunction (within the physical instrument layer) is called on all deletedPI modules at 1416 and the deleted PI modules are unloaded at 1418. NewPIs are loaded at step 1420. Alternatively, after step 1408's call toSystemPI Update the process may proceed directly to 1410 to determine ifdispatcher received new configurations.

The alternative forks of the process 1412 (TRUE) and 1412 (FALSE) meetagain and the process determines whether power is available at thehardware represented by the PI modules at 1422. If power is off1422(FALSE), the PowerOnInit function is called at 1428, if power isavailable 1422(TRUE), the system checks to see if power was off orinterrupted at 1424. If power was off or interrupted 1424(TRUE) thePowerOnInit function is called at 1428. If power was not off orinterrupted 1424(FALSE), the process continues to check if theconfiguration is different at 1426. The previous forks meet again at theconfiguration test. If the configuration is not different 1426 (FALSE)the process returns to main thread execution at 1438. If theconfiguration is different 1426(TRUE) the system will optionallyre-qualify and update the platform state variable“StateRecipeQualified.” (not shown). Alternatively, in response to theidentification of a different configuration 1426(TRUE), a check todetermine if the program is loaded is performed at step 1430. If theprogram is not loaded 1430(FALSE) main thread execution will continue at1438. If the program is loaded 1430(TRUE) a function call IsMappingOK( )is made for all VMIs at 1432. If the mapping is ok for all VMIs,1434(TRUE) main thread execution continues at 1438. If mapping is not okfor all VMIs 1434(FALSE), state variable ProgramNotValid is updated at1436.

In summary, the exemplary process determines if a system is in a poweredon state. Also, if in the powered-on state, the test program and VMIscan successfully meet their requirements to test on the hardwareexisting post-power-cycle or reconfiguration. The VMI holds theresponsibility of this checking, providing another abstraction ofresponsibility away from the platform and provided to the modules.

Once the power state of a system is determined, the next check is tovalidate the actual configuration of the system. As a result of thisprocess, configured PI modules with missing or incorrect hardware willput themselves into a disabled state and publish their resources as“PoweredOff.” If additional hardware is detected that does notcorrespond to a configured PI module, then a ValidateConfigurationprocess (not shown) will publish a warning message. The warning messagecan be returned to a platform user messaging window or to a platformconfigurator to display an intelligent display name if available or an“unknown hardware” message if not.

Alarm Processing

The interaction between the various layers can be further described withrespect to FIG. 15 with an illustration of one embodiment's handling ofalarm processing. FIG. 15 is presented by way of illustration and not byway of limitation.

As can be seen in the embodiment shown in FIG. 15, the variousabstraction layers have been further abstracted into their respectivemodules. In addition, this example shows at the boundary of eachrespective module is at least one interface (1534-1552) designed tomanage communication between the modules. For instance, the SystemPI1504 module has an interface 1538 with the platform layer interface 1532(shown as Platform Software w/Dispatcher) that manages thebi-directional communication with respect to the CheckAlarms functioncall. In this example, the SystemPI module 1504 also has an interface1540 for managing communication and functions with the PI module'sinterface 1542.

In another aspect of the present invention, the platform layerrepresents an abstraction of the functionality employed to log theresults of a process flow. As can be seen with reference to FIG. 15, inone embodiment various function calls performed as part of a processflow report their results to the platform layer. In one embodiment, theplatform layer represents an abstraction of the functionality employedto log the reported results of the various function calls from the otherabstraction layers.

The various function calls and functionality is described with referenceto exemplary alarm process 1500. Exemplary process 1500 is presented byway of illustration and not by limitation. Alarm process 1500 beginswith a CheckAlarms( ) call at 1502 to the SystemPI. In one embodiment,the SystemPI 1504 has full knowledge of the configuration of the testerand holds a list of all occupied locations (location is a platformconcept and may be represented by a 32-bit number acting as an indexinto a list). The Platform/dispatcher 1508 expects a return of a list ofLocations form the SystemPI 1504 which may have alarmed. At 1506, theSystemPI returns a list containing locations that may have alarmed tothe Platform/dispatcher 1508. In one embodiment, this list may befiltered by the SystemPI 1504. In one example, filtering is done basedon the SystemPI's 1504 ability to determine is a PI 1512 is under itspurview. In another example the system is configured to return PIs 1512that are not within a SystemPI's 1504 purview automatically. Toillustrate, a Ceres Native Instrument is within the purview of the CeresSystemPI.

A key concept here is that instruments which are not native to a testercan be easily integrated into an overall test solution—the platforms'interface with the PI module has no expectations of hardwareimplementation. Therefore, in one specific example, a GPIB orPCIExpress-based solution can be integrated exactly as a native-builtsolution allowing for a hardware-independent solution.

At 1510, the ServiceAlarms( ) call is made to each location returned inthe CheckAlarms( ) call to the SystemPI (1502 & 1506). TheServiceAlarms( ) is received and the PI 1512 (or alternatively theSystemPI 1504 (not shown)) accesses its hardware to determine whether anactual alarm state exists. In one embodiment, filtering of alarms by theSystemPI aids in execution time, assisting in maintaining thedeterministic nature of the test platform. In another embodiment, thesystem is configured to not generate Alarms that are not relevant to theaccuracy of a measurement or do not indicate that the hardware is in aninvalid state. The PI 1512 (alternatively the SystemPI 1504 (not shown))reads back the alarm state of the hardware at 1514. Step 1514 may alsoinclude clearing local alarm cache(s), and may include placing hardwareinto a safe state.

On reading back the alarm state, the PI 1512 (alternatively the SystemPI1504 (not shown)) caches alarms by resource, as well as AllSite alarms(global alarms). In one embodiment the cache is maintained until thenext ServiceAlarms( ) call is made. Caching enables alarms to beavailable for tool display.

At 1516, the ReportAlarms( ) call is made to each instantiated VMI 1518.In one embodiment, this call is made independent of whether anylocations were returned in the CheckAlarms( ) call to the SystemPI 1504at 1502 and 1506. According to one example, independent calls toReportAlarms( ) is beneficial because it accounts for alarms treated aspersistent by a PI (e.g. 1512) and when the hardware may not indicate anAlarm to the SystemPI 1504 (this may occur in embodiments where theSystemPI filters alarms based on PIs within its purview) or because asoftware-level alarm may have occurred either in the VMI or with theVMI's mapped resources. The VMI 1518 queries each of its resources, forexample PI 1512 at 1520, to determine if an alarm exists. It should beunderstood that VMI 1518 may have one or more PIs with which itinteracts, and figure should not be interpreted as limiting a VMI to anynumber of PI interactions and their associated resources.

In response to the VMI query PI 1512 responds with the requested alarminformation at 1522 and marks the alarm as reported. PI 1512 may filterout alarms reported back based on design or based on configurations ofthe PI 1512. In addition VMI 1518 may also filter reported alarms basedon design or based on configuration of the VMI 1518. The VMI 1518provides a response regarding its resources with a ms_bool at 1524. Inone embodiment, a response is performed with a bool which is multisitedeep. That is, multisite objects (e.g., ms_bool, ms_float, etc) may becreated which are sized by the number of sites the program is developedto support. VMI 1518 may compile alarms by site as VMI object may bedesigned with comprehension of site. The response from ReportAlarms isreported to the Datalogging service 1554 at 1530. Alternatively, theresponse from ReportAlarms may be combined with other information andreported to the Datalogging service 1554.

GetUnreportedAlarms( ) call is made at 1526 to each instantiated PI 1512(shown is one PI, however many PIs are possible) and the SystemPI 1054.The GetUnreportedAlarms( ) call may be made independent of whether anylocations were returned in the CheckAlarms( ) call (1502 and 1506) andalternatively to the SystemPI 1504 (not shown). In one embodiment, theGetUnReportedAlarms( ) call is only made to the SystemPI and the PIs.The GetUnReportedAlarms( ) call allows for reporting of Alarms byresources which are not mapped to a VMI—the ReportAlarms( ) call to theVMI may be adapted to handle all the alarms for resources mapped to theVMI, whether they are persistent or non-persistent. Persistent alarms orSoftware Alarms are handled by the fact that even if the SystemPIreturns a empty Location List to the CheckAlarms( ) call—theReportAlarms and GetUnreportedAlarms are still carried out.

In one embodiment, PI 1512 returns a 2-bit number in response at 1526where the MSB indicates an AllSites Alarm and the LSB indicates andunreported resource alarm. The response from GetUnreportedAlarms( )reported to the Datalogging Service 1554 at 1532. Alternatively, theresponse may be combined with other information and reported to theDatalogging service 1554, for example the response from ReportAlarms andGetUnreportedAlarms may be combined and sent together to Dataloggingservice 1554.

PowerOnIntitialize (POI) Function

In one embodiment of the present invention, the physical instrumentlayer calls a PowerOnInitialize function as part of the system processthat polls a system's power state. In one embodiment of the presentinvention, the PowerOnInitialize function is included in a physicalinstrument base class of methods. According to one aspect of theinvention, the PowerOnInitialize function is designed to place a PImodule and its hardware into an known initial power state. According toanother aspect of the invention, it is important that the test hardwarepowers into a known safe state because there is no guarantee that theplatform layer is running or that a PI module is configured and loaded.In one embodiment, the PowerOnInitialize function is a member of a baseclass of functions defined in the physical instrument abstraction layer.

FIG. 16 shows an example illustration of one embodiment's implementationof the PowerOnInitialize function, 1600. FIG. 16 describes an exemplarydata flow, and should not be read to limit the present invention eitherto the one function illustrated or this particular data flow.

PowerOnInitialization( ) call is made at 1602. At 1604 a determinationis made whether the PI/Hardware device is dependent upon its systempower state in order to perform its test functions. If it is not1604(FALSE) then the PI local cache is set to initialized state at 1612and state of published resources is updated at 1614. If a PI/Hardwaredevice is dependent upon system power state 1604(TRUE) then a powerstatus check for the system is performed at 1606. In one embodiment aGetPlatformStateInformation( ) call is made to obtain the system powerstatus. In another embodiment the GetPlatformStateInformation( ) call ispart of the PI Base Class of functions. If the system power is not on1608(FALSE) then the PI local cache is set to initialized state at 1612and state of published resources is updated at 1614. If the system powerin on 1608 (TRUE) that PI/hardware device is reset. In one embodiment,resetting is performed to guaranty the PI/hardware device is in a knownstate for testing. Once the PI/hardware device is reset the PI localcache is set to initialized state at 1612 and state of publishedresources is updated at 1614. In one embodiment PI resources have eithera State of PowerOn or PowerOff to identify their power state.

In another embodiment, the virtual instrument layer includes a baseclass of functions that define basic functionality employed to performits functions. In one example, a VI module calls theGetPlaformInformation function to get platform state information. In oneembodiment, the virtual instrument layer includes a function forreporting a list of alarms against its resources. In another embodiment,the alarm reporting function is included in the base class of functions.

According to another aspect of the present invention, the system layerincludes a base class of functions that define basic functionalityemployed to perform its functions. In one example, the platform callsthe UpdateSystemPowerStatus function as part of the PowerPoll processshown in FIGS. 14A-B. In one embodiment, the UpdateSystemPowerStatusfunction is included in the system layer base class of functions. Inanother example, the base class of functions includes a CheckAlarmfunction, adapted to check whether locations have alarms returning alist of alarms.

Software Wizards and Rules Checking Engines

According to one aspect of the invention, the abstraction offunctionality includes abstracting the functionality employed to operatesoftware wizards adapted to generate interfaces between the variousabstraction layers. In one embodiment, the abstraction of functionalityincludes an interface generation engine adapted to generate interfacesthat manage communication between the various abstraction layers. In oneembodiment, the interface generation engine represents the abstractionof the functionality employed to define an interface between a module inthe system layer and a module in the physical instrument layer. In oneembodiment, the interface generation engine represents the abstractionof the functionality employed to define an interface between a module inthe virtual instrument layer and a module in the physical instrumentlayer. In one embodiment, the interface generation engine represents theabstraction of the functionality employed to define an interface betweena module in the virtual instrument layer and a module in the systemlayer. In another embodiment, the interface generation engine representsthe abstraction of the functionality employed to define an interfacebetween a SystemPI module, PI Module, VI Module and the platform layer.

In another embodiment, the abstraction of functionality includesabstraction of the functionality employed to operate software wizardsadapted to generate modules of the various abstraction layers. In oneembodiment, the abstraction of functionality includes a modulegeneration engine adapted to define a module in one of the abstractionlayers. In one embodiment, the module generation engine represents theabstraction of the functionality employed to define a VI module. Inanother embodiment, the module generation engine represents theabstraction of the functionality employed to define a PI module. Inanother embodiment, the module generation engine represents theabstraction of the functionality employed to define a SystemPI module.In another embodiment, the module generation engine may represent theabstraction of the functionality employed to define a platform module.

According to one aspect of the present invention, the generated modulesneed to be verified to insure appropriate mapping between the variousabstraction layers. According to another aspect of the presentinvention, generated modules must be verified to insure appropriatefunctionality. In one embodiment, a rules checking engine represents anabstraction of the functionality employed to verify the appropriatemapping of generated modules and to insure appropriate functionality.For instance, in one implementation, the SystemPI and PI perform rulechecking to verify that they can work with each without adverseinteraction. The VMI may perform rule checking to verify that themapping of resources to it maintains needed rules to function correctly.

It should be appreciated that the invention is not limited to each ofthe embodiments listed above and described herein, but rather, variousembodiments of the invention may be practiced alone or in combinationwith other embodiments.

Having thus described several aspects of at least one embodiment of thisinvention, it is to be appreciated various alterations, modifications,and improvements will readily occur to those skilled in the art. Suchalterations, modifications, and improvements are intended to be part ofthis disclosure, and are intended to be within the spirit and scope ofthe invention. Accordingly, the foregoing description and drawings areby way of example only.

What is claimed is:
 1. A computer implemented method for automatedtesting of computing equipment, the method comprising: performing aprocedure on test hardware through a test program the procedureincluding a request for a test function; decoupling the test programfrom the test hardware through an abstraction layer; generating withinthe abstraction layer, a virtual instrument (“VI”) layer withouthardware implementation-specific functionality; receiving, by the VIlayer, at least one request from the test program through at least onevirtual instrument virtual instrument (“VI”) interface, wherein said VIinterface is implemented as an add-only programming interface using avirtual instrument virtual function table to allow backward-compatibleupgrades; (b) map the request from the test program into a function callto a hardware-specific physical instrument layer; (c) communicate thefunction call to at least one hardware-specific physical instrumentlayer; receiving the function call from the virtual instrument layerthrough a virtual instrument (“VI”) to physical instrument interface(“PI”); and communicating the function call to a hardware-specificphysical instrument (“PI”) layer including at least one physicalinstrument (“PI”) module representing the hardware specificimplementation of a test instrument, wherein said VI to PI interface isimplemented as an add-only programming interface using a physicalinstrument virtual function table to allow backward-compatible upgrades;(b) map the functional call into a hardware specific instruction for atleast one test instrument in the test hardware; and (c) communicate thehardware-specific instruction to the test instrument for execution. 2.The method of claim 1, further comprising an act of updating at leastone of the VI interface or VI to PI interface, wherein updates aregenerated only by adding additional functionality to at least one of thevirtual instrument virtual function table or the physical instrumentvirtual function table to ensure backward compatibility.
 3. The methodaccording to claim 1, wherein at least one virtual instrument interfacefurther comprises a virtual multisite (“VMI”) interface.
 4. The methodaccording to claim 1, wherein the abstraction layer further comprises asystem physical instrument (“SystemPI”) interface to the platform. 5.The method according to claim 1, wherein the abstraction layer furthercomprises a physical instrument (“PI”) interface to the platform.
 6. Themethod according to claim 1, wherein the abstraction layer furtherincludes a system physical instrument (“SystemPI”) to virtual instrument(“VI”) interface.
 7. The method according to claim 1, wherein theabstraction layer further includes a system physical instrument(“SystemPI”) to physical instrument (“PI”) interface.
 8. The methodaccording to claim 1, wherein the abstraction layer further includes atest program to virtual instrument (“VI”) interface.
 9. The methodaccording to claim 1, wherein the abstraction layer further includes atest program to physical instrument (“PI”) interface.
 10. The methodaccording to claim 1, wherein the abstraction layer further includes aplatform to virtual instrument (“VI”) interface.
 11. The methodaccording to claim 1, wherein the abstraction layer further includes aplatform to physical instrument (“PI”) interface.
 12. The methodaccording to claim 1, wherein the abstraction layer further includes aplatform to virtual multisite instrument (“VMI”) interface.
 13. Themethod according to claim 1, further comprising displaying a graphicaluser interface adapted to guide a user through generation of aninterface.
 14. The method according to claim 1, wherein displaying thegraphical user interface includes an act of guiding the user throughgeneration of an interface configured to manage communication betweenthe abstraction layer and a test instrument.
 15. The method according toclaim 14, wherein the method further comprises: generating an interface;and mapping the plurality of function calls to instructions to beexecuted on test hardware.
 16. The method according to claim 15, whereinmapping the plurality of function calls includes mapping the pluralityof function calls to a virtual instrument (“VI”) module.
 17. The methodaccording to claim 1, wherein generating the virtual instrument layerincludes generating a virtual instrument (“VI”) module and mapping theVI module to at least one hardware resource.
 18. The method according toclaim 17, wherein managing execution of instructions on a hardwareresource in response to requests.
 19. The method according to claim 17,wherein mapping to at least one resource includes mapping executionthrough at least one PI module for each of the at least one hardwareresources.
 20. The method according to claim 19, wherein mappingincludes mapping the VI module to a plurality of PI modules to render avirtual representation of a set of predefined hardware resourcesemployed to test a particular device.